Sergio Salvi wrote:
I've applied both patches into this branch:
http://dev.catalyst.perl.org/svnweb/Catalyst/browse/branches/Catalyst-Plugin-Session/both/
Hi, sorry for the very late followup on this, but it's been noted that
the documentation wasn't adjusted to reflect the changes made.
I d
On Thu, Dec 11, 2008 at 12:04 PM, Sergio Salvi wrote:
> On Thu, Nov 20, 2008 at 4:49 PM, Tobias Kremer wrote:
>> On 20.11.2008, at 21:16, Sergio Salvi wrote:
>>>
>>> I still think the final solution (besides finding a way to make
>>> find_or_create() atomic), is to store flash data the session ro
On Thu, Nov 20, 2008 at 4:49 PM, Tobias Kremer wrote:
> On 20.11.2008, at 21:16, Sergio Salvi wrote:
>>
>> I still think the final solution (besides finding a way to make
>> find_or_create() atomic), is to store flash data the session row
>> (either on the same column of session or on a new, dedic
On 20.11.2008, at 21:16, Sergio Salvi wrote:
I still think the final solution (besides finding a way to make
find_or_create() atomic), is to store flash data the session row
(either on the same column of session or on a new, dedicated column).
Sergio++
FWIW, I rolled my own flash mechanism whi
On Fri, Sep 26, 2008 at 3:49 PM, Daniel Westermann-Clark <[EMAIL PROTECTED]>
wrote:
> On 2008-08-26 09:47:59 +0200, Tobias Kremer wrote:
>> a) Patch Catalyst::Plugin::Session::Store::DBIC to wrap the flash
>>functionality in a transaction (of course, this must be
>>configurable).
>
> I've
On 2008-08-26 09:47:59 +0200, Tobias Kremer wrote:
> a) Patch Catalyst::Plugin::Session::Store::DBIC to wrap the flash
>functionality in a transaction (of course, this must be
>configurable).
I've released a new version which includes this functionality:
0.07 Wed Sep 24 17:08:34 EDT 2008
Quoting Jonathan Rockway <[EMAIL PROTECTED]>:
> * On Wed, Aug 27 2008, Tobias Kremer wrote:
> > We definitely should! IMHO five queries per request to the database just
> > for the session and flash stuff is inacceptable.
> If your app is really slowed by the number of queries to load
> session/fla
* On Wed, Aug 27 2008, Tobias Kremer wrote:
> Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>:
>
>> On 2008-08-26 14:18:18 +0200, Tobias Kremer wrote:
>> > Just out of pure curiosity: Why is it that there are dedicated
>> > "flash:" entries in the storage for the flash? Wouldn't the
>> > sessio
On Wed, Aug 27, 2008 at 10:41:11AM +0200, Tobias Kremer wrote:
> Quoting Moritz Onken <[EMAIL PROTECTED]>:
> > Am 27.08.2008 um 10:19 schrieb Tobias Kremer:
> > > Ok, a second glance (after the first coffee) revealed that the
> > > separation is indeed there :) The question is, why?
> >
> > Just gu
Quoting Moritz Onken <[EMAIL PROTECTED]>:
> Am 27.08.2008 um 10:19 schrieb Tobias Kremer:
> > Ok, a second glance (after the first coffee) revealed that the
> > separation is indeed there :) The question is, why?
>
> Just guessing:
> not every request has its own session object. There are users wit
Am 27.08.2008 um 10:19 schrieb Tobias Kremer:
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>:
The "flash:" rows were used for compatibility with Store::DBI. We
can
break compatibility if people find the it not very useful.
I have to admit t
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
> Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>:
> > The "flash:" rows were used for compatibility with Store::DBI. We can
> > break compatibility if people find the it not very useful.
> I have to admit that I don't understand what compatibility w
Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>:
> On 2008-08-26 09:47:59 +0200, Tobias Kremer wrote:
> > Please note, that this is ONLY happening with the flash part - my
> > sessions work 100% accurate all the time!
> How are you interacting with the flash vs. your sessions? Could you
> prov
Quoting Daniel Westermann-Clark <[EMAIL PROTECTED]>:
> On 2008-08-26 14:18:18 +0200, Tobias Kremer wrote:
> > Just out of pure curiosity: Why is it that there are dedicated
> > "flash:" entries in the storage for the flash? Wouldn't the
> > session be enough?
>
> The "flash:" rows were used for co
On 2008-08-26 09:47:59 +0200, Tobias Kremer wrote:
> a) Patch Catalyst::Plugin::Session::Store::DBIC to wrap the flash
>functionality in a transaction (of course, this must be configurable).
>Advantages:
> - Easy to implement
> - Most sensible solution.
>Disadvantages:
>
On 2008-08-26 14:18:18 +0200, Tobias Kremer wrote:
> Just out of pure curiosity: Why is it that there are dedicated
> "flash:" entries in the storage for the flash? Wouldn't the
> session be enough?
The "flash:" rows were used for compatibility with Store::DBI. We can
break compatibility if peopl
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
> just wanted to inform you that switching from MyISAM to InnoDB for the
> session table does NOT solve the "duplicate entry" problem when
> using flash() :(
Just out of pure curiosity: Why is it that there are dedicated "flash:"
entries in the storage f
On Tue, Aug 26, 2008 at 09:47:59AM +0200, Tobias Kremer wrote:
[...]
> b) Patch DBIx::Class's find_or_create() method and reverse its order
>(insert first, check for duplicate, then select).
>Disadvantages:
> - Not that easy to implement because every database returns
>a differ
Hey guys,
just wanted to inform you that switching from MyISAM to InnoDB for the session
table does NOT solve the "duplicate entry" problem when using flash() :(
I really can't believe that me and 3 or 4 others are the only people
experiencing this problem! We're getting close to 400 of those err
On 29 Jul 2008, at 12:30, Tobias Kremer wrote:
> The short time window between the find() and create() calls of the
> find_or_create() method indeed is the problem. It sounds like this
> window should be too small to ever happen but in reality it happens very
> often in our (and other's) applicatio
On Tue, Jul 29, 2008 at 12:49:17PM +0200, Tobias Kremer wrote:
> Quoting Tobias Kremer <[EMAIL PROTECTED]>:
> > However, I'm unsure how to detect if the error really was a duplicate entry
> > error or something else.
> > die $@ if $@ && $@ !~ /duplicate/i;
> > This doesn't work because different
On 2008-07-28 22:33:44 +0100, Matt S Trout wrote:
> > Is there anything speaking against wrapping line 52 of the DBIC
> > backend class with an eval to trap this duplicate error and ignore
> > it silently (or just warn about it) except the fact that it's
> > trying to fix something that probably sh
Quoting Nigel Metheringham <[EMAIL PROTECTED]>:
> On 29 Jul 2008, at 12:30, Tobias Kremer wrote:
> > The short time window between the find() and create() calls of the
> > find_or_create() method indeed is the problem. It sounds like this
> > window
> > should be too small to ever happen but in rea
On 29 Jul 2008, at 12:30, Tobias Kremer wrote:
The short time window between the find() and create() calls of the
find_or_create() method indeed is the problem. It sounds like this
window
should be too small to ever happen but in reality it happens very
often in our
(and other's) application
Quoting Ash Berlin <[EMAIL PROTECTED]>:
> Maybe this was mentioned in earlier in the thread, (or perhaps this is
> the problem in the first place?), but DBIx::Class does have a
> find_or_create method.
The short time window between the find() and create() calls of the
find_or_create() method indee
On 29 Jul 2008, at 11:49, Tobias Kremer wrote:
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
However, I'm unsure how to detect if the error really was a
duplicate entry
error or something else.
die $@ if $@ && $@ !~ /duplicate/i;
This doesn't work because different DBs throw different errors.
Quoting Tobias Kremer <[EMAIL PROTECTED]>:
> However, I'm unsure how to detect if the error really was a duplicate entry
> error or something else.
> die $@ if $@ && $@ !~ /duplicate/i;
> This doesn't work because different DBs throw different errors.
Also, flash() is supposed to always return a
Quoting Matt S Trout <[EMAIL PROTECTED]>:
> On Mon, Jul 28, 2008 at 01:03:52PM +0200, Tobias Kremer wrote:
> > Is there anything speaking against wrapping line 52 of the DBIC backend
> > class with an eval to trap this duplicate error and ignore it silently
> > (or just warn about it) except the fa
On Mon, Jul 28, 2008 at 01:03:52PM +0200, Tobias Kremer wrote:
> Hi list,
>
> I've written about this at least once in the past and still haven't been able
> to
> figure out a proper solution to the problem.
>
> We're getting loads (up to 30-40 per day) of the following fatal error:
>
> Duplica
Tobias Kremer wrote:
This is a different problem than the one discussed last week or so! I'm pretty
sure it's a classic race-condition.
Then I would suggest placing a lock around the critical region of code.
IPC::SRLock perhaps (which I wrote)
--
Regards
___
Quoting Peter Flanigan <[EMAIL PROTECTED]>:
> Tobias Kremer wrote:
> > Duplicate entry 'flash:***' for key 1 [for Statement "INSERT INTO sessions2
> > (id) VALUES (?)" with ParamValues: 0='flash:***'] at
> > /usr/local/lib/perl5/site_perl/5.8.8/Catalyst/Plugin/Session/Store
> > /DBIC/Delegate.pm li
Tobias Kremer wrote:
Duplicate entry 'flash:***' for key 1 [for Statement "INSERT INTO sessions2 (id)
VALUES (?)" with ParamValues: 0='flash:***'] at
/usr/local/lib/perl5/site_perl/5.8.8/Catalyst/Plugin/Session/Store/DBIC/Delegate.pm
line 52"
What is the length of the id field in the sessions2
Hi list,
I've written about this at least once in the past and still haven't been able to
figure out a proper solution to the problem.
We're getting loads (up to 30-40 per day) of the following fatal error:
Duplicate entry 'flash:***' for key 1 [for Statement "INSERT INTO sessions2 (id)
VALUES (
33 matches
Mail list logo
