[Catalyst] Session duplicate key constraints on concurrent requests

[Tobias Kremer]

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] Created session "new-session-id"

This leads me to believe that Session::Store::DBIC is simply broken!

I'll try switching to Store::DBI for now and see if that solves the
problem in production.

--Toby



On Mon, Oct 10, 2011 at 2:56 PM, Tobias Kremer <tobias.kremer at gmail.com> wrote:
> On Mon, Oct 10, 2011 at 2:26 PM, Matthias Dietrich <mdietrich at 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 Store::Memcached for
> example, one session would overwrite the other's data, thus you'll
> loose data anyways. There's no perfect solution to this problem, I
> guess :)
>
> On Mon, Oct 10, 2011 at 1:53 PM, Janne Snabb <snabb at epipe.com> wrote:
>> I think the browser will hold on to the session that it receives later.
>
> That's exactly what would happen, because the browser will store only
> the last cookie it received.
>
> Due to the few responses we've received so far, I take it that
> nobody's really using the DBIC backend in a medium-sized app? What's
> your favorite session backend (that works in a load-balanced
> environment) and handles quite a lot of traffic? :)