The sessions are in a standard Oracle table in which the primary key is the session id and the session data is a blob. The session should be retrieving the correct data. I think we'd have noticed long before now if the data wasn't be committed properly. (Autocommit is on anyway.)
I reduced the number of fastcgi processes from 5 to 1 and the problem went away.
This may mean that the race condition doesn't show up with one process.
However it may mean that the processes don't coordinate properly.
Should we have done something to make the session handling more sophisticated when we increased the number of fastcgi processes? For example do we have to do something explicit to lock a particular session to a particular process?
From: Andrew Rodland
Sent: 29 March 2011 19:33
To: The elegant MVC web framework
Subject: Re: [Catalyst] Force the session to be saved.
On Tuesday, March 29, 2011 12:46:32 PM Duncan Garland wrote:
We've been having some peculiar behaviour from our system. I think it's
because the controller which produces the HTML page stores data in the
session for retrieval by the controller which produces the associated
The client begins processing the HTML page as soon as it starts to arrive.
Occasionally the first controller hasn't written the session to the
I can move the script tag down the page a bit, but what I really need is a
way to force the session to be written before the HTML template is
Is there such a method?
finalize_session (which writes the session to the DB) runs before
finalize_body (which writes the response to the client), so Catalyst already
does what you would like it to, and forcing a session write before running the
view is unlikely to help anything. I suspect either your database isn't
guaranteeing ordering, or the problem is somewhere other than where you're
Searchable archive: http://firstname.lastname@example.org/
Dev site: http://dev.catalyst.perl.org/