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
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
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