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.
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.
Has anyone come up with an optimistic locking solution for Rails session
to get around this race condition issue?
On Apr 20, 10:45 pm, Jonathan R. <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?
trunk actually uses a pessimistic lock on the session, I have a not
yet fully battle tested branch that uses optimistic locking.
Fred