On Apr 20, 10:45 pm, Jonathan Rochkind <rails-mailing-l...@andreas-
s.net> wrote:> Okay, continuing in my project of abusing Rails horribly.
>
> It looks to me like even standard Rails sessions are subject to a race
> condition if the same session is accessed concurrently. Request1 checks
> out a session. Request 2 checks out a session, makes a change, and
> writes it back to the store. Request 1, still finishing up, makes a
> change, and writes the session back to the store... overwriting the
> changes Request2 made.
>
Completely. See
http://www.paulbutcher.com/2007/05/race-conditions-in-rails-sessions-and-how-to-fix-them/
for how we dealt with this at work.
> So, if I''m using an ActiveRecord store... what happens if I just
add a
> lock_version column to the model? But then I guess an exception will be
> raised from the innards of ActiveController somewhere. And it would be
> unclear how to recover from it. So that''s not quite right.
>
Yup, not quite as simple as just detecting the error condition.
> Has anyone come up with an optimistic locking solution for Rails session
> to get around this race condition issue?
http://github.com/fcheung/smart_session_store/tree/master
trunk actually uses a pessimistic lock on the session, I have a not
yet fully battle tested branch that uses optimistic locking.
Fred> --
> Posted viahttp://www.ruby-forum.com/.