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
On Thu, Dec 11, 2008 at 12:04 PM, Sergio Salvi sergio.li...@salvi.ca wrote:
On Thu, Nov 20, 2008 at 4:49 PM, Tobias Kremer l...@funkreich.de 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
On Thu, Nov 20, 2008 at 4:49 PM, Tobias Kremer l...@funkreich.de 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
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 released a
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
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 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:hash entries in the storage for the flash? Wouldn't the
session be enough?
The flash: rows were used for
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
provide some
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 that I
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 with no
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 guessing:
not
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:hash
entries in the storage for
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 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) applications.
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 DBs throw
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 fact that
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)
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 should be
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
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 line 52
What
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
21 matches
Mail list logo
