Rails - May 2009 - Can I update session variable in a new thread?

Hi,

I have a controller code which does the following

t1= Thread.new {
       #some code
       session[:executing] = "done"
    }

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?

Regards,
Sudhi
-- 
Posted via http://www.ruby-forum.com/.

On May 26, 10:20 am, Sudhi Kulkarni
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Hi,
>
> I have a controller code which does the following
>
> t1= Thread.new {
>        #some code
>        session[:executing] = "done"
>     }
>
> 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?
>
If this ends up setting the session after rails has closed out the
session (ie pushed it back into the db, or sent the cookie back to the
client) then this won''t work.

Fred
> Regards,
> Sudhi
> --
> Posted viahttp://www.ruby-forum.com/.

Frederick Cheung wrote:
> On May 26, 10:20�am, Sudhi Kulkarni
<rails-mailing-l...@andreas-s.net>
> wrote:
>> session[:executing] it is not updated to "done". Is there a
problem if I
>> try to update session variable in a different thread?
>>
> 
> If this ends up setting the session after rails has closed out the
> session (ie pushed it back into the db, or sent the cookie back to the
> client) then this won''t work.
> 
> Fred
How do I know whether rails has closed out and pushed the cookie back to 
client? If I add a join before exiting from the action something like 
below

def execute
t1 = Thread.new { #code
                  session[:executing] ="done";
                }

t1.join
end

In the above case the session variable is updated. How would I get this 
working if I want the session to be updated sometime later and still not 
in that function?

Regards,
Sudhindra
-- 
Posted via http://www.ruby-forum.com/.

On May 27, 4:36 am, Sudhi Kulkarni
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Frederick Cheung wrote:
> How do I know whether rails has closed out and pushed the cookie back to
> client?
There''s going to be a pretty narrow window after your action method
returns and before rails has got as far as session cleanup. I can''t
think you''d gain anything by waiting for your thread to exit there
rather than in your action.

Fred
> If I add a join before exiting from the action something like
> below
>
> def execute
> t1 = Thread.new { #code
>                   session[:executing] ="done";
>                 }
>
> t1.join
> end
>
> In the above case the session variable is updated. How would I get this
> working if I want the session to be updated sometime later and still not
> in that function?
>
> Regards,
> Sudhindra
> --
> Posted viahttp://www.ruby-forum.com/.

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:

http://www.ruby-forum.com/topic/184782

And see if it makes any sense to you, or still seems worth it to you 
when you see what you must do. :)  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.
-- 
Posted via http://www.ruby-forum.com/.

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.
-- 
Posted via http://www.ruby-forum.com/.

>> 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.
Sorry, this is a topic of interest to me that noone else is ever 
interested in talking about.

PPS:   REALLY, if you decide you want to set off a thread that will 
persist after the response is returned, despite the general pain in the 
neck of doing that cause neither ActiveRecord nor MRI 1.8 Ruby are 
entirely happy with it (but it''s still possible if you take the right 
precautions)...

AND... you need that thread to store state that later requests can 
access....

Consider just storing it in the db as an ActiveRecord rather than trying 
to put it in a session. All in all easier to deal with, at least if your 
thread already was using ActiveRecord anyway (which supplies it''s own 
headaches).  Worth considering, it''s a trade-off as to what sort of 
headaches you want to deal with.
-- 
Posted via http://www.ruby-forum.com/.