# Optimistic locking with session store?

**URL:** <https://www.ruby-forum.com/t/optimistic-locking-with-session-store/166004>\
**Category:** Rails\
**Created:** [April 20, 2009, 11:45pm UTC](https://www.ruby-forum.com/t/optimistic-locking-with-session-store/166004 "2009-04-20T23:45:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jrochkind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/779978/32.png) [@jrochkind](https://www.ruby-forum.com/u/jrochkind)\
**Post date:** [April 20, 2009, 11:45pm UTC](https://www.ruby-forum.com/t/optimistic-locking-with-session-store/166004/1 "2009-04-20T23:45:50Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jrochkind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/779978/32.png) [@jrochkind](https://www.ruby-forum.com/u/jrochkind)\
**Post date:** [April 21, 2009, 9:20am UTC](https://www.ruby-forum.com/t/optimistic-locking-with-session-store/166004/2 "2009-04-21T09:20:21Z")

</div>

On Apr 20, 10:45 pm, Jonathan R. \<rails-mailing-l…@andreas-  
[s.net](http://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/](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?

> **[GitHub - fcheung/smart\_session\_store: a session store that helps to mitigate...](https://github.com/fcheung/smart_session_store/tree/master)**
>
> master

trunk actually uses a pessimistic lock on the session, I have a not  
yet fully battle tested branch that uses optimistic locking.

Fred