Can I update session variable in a new thread?

Sudhi Kulkarni wrote:

Then in one of the periodic update methods if I access the session[:executing] it is not updated to "done". Is there a problem if I try to update session variable in a different thread?

Actually, this is precisely what I was trying to do in another thread here where Fred graciously helped me too. I'd advise NOT trying to use the session array Rails gives to you, but instead just telling the thread the sessionID, and ten doing all the session access yourself manually. That's what I'm doing. It's not TOO hard, although it inconveniently changes for Rails 2.2 vs. pre-Rails 2.2.

See this:

And see if it makes any sense to you, or still seems worth it to you when you see what you must do. :slight_smile: But it does seem to be working for me, with some basic unit tests.

There's sadly one more added wrinkle with regard to race conditions when you start to deal with sessions like this, that can result in the main action over-writing the session data the thread tries to write, or vice-versa. I have a hacky way to minimize (although not totally eliminate that), that is Session-store agnostic. You can totally eliminate it if you're willing to hack the particular session store, as I believe Fred has also done for the AR store, but I think this is quickly getting beyond what you hoped would be an easy answer.

But it is do-able, although not easy, I don't think you can get away with just trying to access the session array itself in a thread that's out of the request loop.

Jonathan Rochkind wrote:

But it is do-able, although not easy, I don't think you can get away with just trying to access the session array itself in a thread that's out of the request loop.

I'd add it's do-able ONLY if you are using a server-side session store. NOT if you are using the cookie store that's the new Rails default. With the cookie store there's simply no possible way to write to the session outside the request loop. So if you want to write to a session in a thread, you'd have to wait() on the thread before returning from your action, which might defeat the purpose you were trying to use the thread for in the first place.

Also, if you are planning on using ActiveRecord in this thread, you've got to make sure to do a few other things to ensure your AR calls are thread-safe. Things which change slightly in different Rails versions, as Rails community has changed it's consensus on what sorts of threading are 'supported' in what ways.

And ALSO, even aside from AR, I learned the hard way that (at least if you're using the standard 1.8 MRI ruby interpreter), if you want to send a thread off and let it keep going outside the request-loop, you'd really better set it's priority to -1, or it's going to end up interfering with your response being returned even though you don't think it should.

Contrary to popular belief, it IS possible to do concurrent programming like this in Rails, in all versions. But it's a big pain in the neck. Don't do it unless you really have to (which I think I do in my situation), try to find another solution if possible.