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.kre...@gmail.com> wrote: > 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 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 <sn...@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? :) _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/