To get the discussion back on track: I switched from
Session::Store::DBIC to Session::Store::DBI on our production systems
a couple of hours ago and haven't had a single duplicate key
constraint error. Yay!
I'll file a bug report for C::P::Session::Store::DBIC.
Cheers!
--Toby
On Tue, Oct 11,
On 10 October 2011 16:00, Tobias Kremer tobias.kre...@gmail.com wrote:
On Mon, Oct 10, 2011 at 4:07 PM, Matthias Dietrich mdietr...@cpan.org wrote:
Am 10.10.2011 um 15:59 schrieb Denny:
The word you both want is 'lose'. Loose means something slightly different
(and slightly odd, when
Here's an interesting fact: Whenever I hit MyApp with an invalid
session id (i.e. one, that isn't in the store), the plugin tries to
insert this exact session id. If two concurrent requests with an
invalid session come in, they both try to (re-)create this invalid
session. This is due to the use
On Mon, 10 Oct 2011, Tobias Kremer wrote:
So, isn't the use of find_or_create() just plain wrong or am I seeing
things here? :)
I have been thinking also that the correct solution might be as
simple as to just replace find_or_create() with find(), but I have
not managed to have a look at upper
Hi,
Am 10.10.2011 um 10:42 schrieb Tobias Kremer:
a) Try to find the session, e.g. $self-model-find({ $self-id_field = $key
})
b) If found, use this session because it's still valid.
c) If not found, create() an entirely NEW(!) session, with a new
session-ID and insert it.
wouldn't that
On Mon, Oct 10, 2011 at 2:26 PM, Matthias Dietrich mdietr...@cpan.org wrote:
wouldn't that result in two new sessions? Your first request would create
session:new1 and the second session:new2, so you'll end up loosing info
from session:new1.
Yes, but does that really matter? If you're using
I just tried Session::Store::DBI and guess what: It does exactly what
I suggested in my previous e-mail and doesn't cause any duplicate key
constraint errors (even with 50 concurrent requests):
[debug] Found sessionid invalid-session-id in cookie
[debug] Deleting session(session expired)
[debug]
The word you both want is 'lose'. Loose means something slightly different
(and slightly odd, when discussing data).
Tobias Kremer wrote:
Matthias Dietrich wrote:
you'll end up loosing info from session:new1.
you'll loose data anyways.
___
Am 10.10.2011 um 15:59 schrieb Denny:
The word you both want is 'lose'. Loose means something slightly different
(and slightly odd, when discussing data).
Your right ;-).
--
rainboxx Software Engineering
Matthias Dietrich
rainboxx Matthias Dietrich | Phone: +49 7141 / 2 39 14 71
On Mon, Oct 10, 2011 at 4:07 PM, Matthias Dietrich mdietr...@cpan.org wrote:
Am 10.10.2011 um 15:59 schrieb Denny:
The word you both want is 'lose'. Loose means something slightly different
(and slightly odd, when discussing data).
Absolutely! Sorry for the typo :)
Your right ;-).
And
Am 10.10.2011 um 17:00 schrieb Tobias Kremer:
Your right ;-).
And that's almost as bad as would of been ... ;-)
*tired
$son is consuming too much time during the nights ;-).
Back on topic:
Am 10.10.2011 um 14:56 schrieb Tobias Kremer:
Yes, but does that really matter? If you're using
On Fri, 7 Oct 2011, Tobias Kremer wrote:
I appreciate your taking the time to look into this. Unfortunately
your patches are for the Store::DBI backend, whereas I'm using
Store::DBIC (DBIx::Class).
So, the code you are talking about is then
Catalyst/Plugin/Session/Store/DBIC/Delegate.pm? It
On Sat, 8 Oct 2011, Janne Snabb wrote:
return $self-model-find_or_create({ $self-id_field = $key })
Just an update:
I discussed about this with mst on irc and we concluded that my
initial suggestion for the fix is also not correct. It is likely
to eliminate the SQL error but also likely to
Dear all,
I've written about this issue a couple of times in the past and it
seems that this still hasn't been fixed. Here's what's happening:
1. Request A comes in with an expired session cookie, C::P::Session
tries to find the session for the given cookie but finds nothing.
2. Meanwhile,
On Friday 07 October 2011 14:48:14 Tobias Kremer wrote:
I've written about this issue a couple of times in the past and it
seems that this still hasn't been fixed. Here's what's happening:
1. Request A comes in with an expired session cookie, C::P::Session
tries to find the session for the
On Friday 07 October 2011 14:48:14 Tobias Kremer wrote:
3. Both requests try to insert a new session, one succeeds, the other
dies(!) with a duplicate key constraint error from MySQL.
Sounds like this should be changed from insert to insert_or_update
which is wrapped within a transaction with
On Fri, 7 Oct 2011, Erik Wasser wrote:
How will the session key calculated? Any idea? Randomly? So two random
processes will calculate the same session value?
It is still the same session cookie as before, but it has already
expired from the database? Thus both sessions try to re-insert it
On Fri, 7 Oct 2011, Janne Snabb wrote:
I think the proper way to solve it is to drop the constraint on the
cookie and just insert the cookie and have an auto_increment ID in
the table. And when reading, select the cookie with the highest ID
(because there might be several).
Something like
On Fri, 7 Oct 2011, Janne Snabb wrote:
Something like this perhaps? Untested code.
Sorry about flooding. This is another much simpler solution but works
only on MySQL. I think there is no standard SQL syntax to accomplish
the same without extra DB fields.
--
Janne Snabb / EPIPE Communications
Hi Janne,
I appreciate your taking the time to look into this. Unfortunately your patches
are for the Store::DBI backend, whereas I'm using Store::DBIC (DBIx::Class).
The INSERT IGNORE solution is probably exactly what this case needs, but as you
said, it's MySQL-specific and thus not suitable
20 matches
Mail list logo
