We’ve been having a few niggles with session management, and I’ve just
released a plugin that deals with them.
In a nutshell there are problems when you have multiple concurrent
requests (several ajax calls, multiple browsers) from the same user
which lead to one action overwriting the changes made by another action.
If two actions are both trying to change the same key in the session
then there isn’t an awful lot you can do, however if the changes are to
different parts of the session there’s no reason why we can’t be a
little smarter about how we save the session.
You can find a more detailed description of the problem and our solution
at
http://about.82ask.com/2007/05/01/race-conditions-in-rails-sessions-and-how-to-fix-them/
If you’re too impatient to read the blog post then the plugin is at
http://svn1.hosted-projects.com/fcheung/smart_session_store/trunk
I’d be happy to here any comments or suggestions you have.
Fred
You might be interested in http://dev.rubyonrails.org/changeset/6184,
if you haven’t already seen it. It introduces cookie-based sessions
to Rails and that alone might alleviate the problem.
–steve
Steve R. wrote:
You might be interested in http://dev.rubyonrails.org/changeset/6184,
if you haven’t already seen it. It introduces cookie-based sessions
to Rails and that alone might alleviate the problem.
–steve
Oops - I think that’s the wrong changeset! But anyway I had heard about
cookie-based sessions. I haven’t tried them, but I don’t think they
solve the base problem: if when you close the session you don’t attempt
to reconcile your changes with the session with changes made by other
actions that ran concurrently, then you’ll get the problems I describe.
In fact I think cookie based storage makes it impossible to do what I
did: with any other store you can reload the session to get the absolute
latest version, with a cookie store you obviously can’t do that.
Fred
Steve R. wrote:
My hope was one browser, one process (the client) controlling
session, less likelihood of race condition. Anyhow, if you’ve
identified the issue, it would be great to have a test to run against
the new session strategy to see if it breaks. Just a thought.
It would be hard to write an actual unit test for this, given that it
depends on the browser’s handling of stuff but it should be easy enough
for me to try the test scenario I wrote up. I’ll give it a go sometime
today.
Fred
It would be good if Rails Core knew about this. FWIW, here are the
comments on 6184:
“Introduce a cookie-based session store as the Rails default.
Sessions typically contain at most a user_id and flash message; both
fit within the 4K cookie size limit. A secure hash is included with
the cookie to ensure data integrity (a user cannot alter his user_id
without knowing the secret key included in the hash). If you have
more than 4K of session data or don’t want your data to be visible to
the user, pick another session store. Cookie-based sessions are
dramatically faster than the alternatives.”
My hope was one browser, one process (the client) controlling
session, less likelihood of race condition. Anyhow, if you’ve
identified the issue, it would be great to have a test to run against
the new session strategy to see if it breaks. Just a thought.
–steve
I’ve just tried this with edge rails and cookie store. As I suspected
cookie store doesn’t not fix the problem. I’d love rails-core folks to
take a look at this, not sure what the best way to get their attention
though.
Fred
Submit a ticket at http://dev.rubyonrails.org/newticket. Provide as
much information an possible and your plugin as a potential fix.
Volunteer to create a patch and see if you get any +1’s.
An inexpensive fix that precludes a race condition could save people
with a certain category of application a ton of debugging time.
–steve
In case anyone is playing around with this, I just committed a bugfix I
heartily recommend you update to
Fred