Rails - May 2013 - Storing Rails controller callback data in session

http://stackoverflow.com/questions/16770090/storing-rails-controller-callback-data-in-session

The idea is:

   - Perform some time consuming action in background.
   - Have the results from that action be propagated back to the controller 
   using a callback.
   - Store the result in an in memory session store.
   - Have the result in session be used and available from that point 
   onward.

Controller receives the results in the callback, as expected.

# controller callback, saves result to session# this method is executed as
expected# session id matches the one from other controller actionsdef
on_counter_value_calculated(context, new_value)
  @counter = new_value
  session[:counter] = @counterend

However, stored session is *lost* in subsequent calls.

# although the same session is targeted (same id)# the saved value is not the
samedef index
  @counter = session[:counter] || 0end

I''ve created a small Rails project that demonstrates the issue:
https://github.com/elvanja/controller_callbak_store_in_session

Any input appreciated.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/2b876660-521d-4217-9840-8fbbe2ac6364%40googlegroups.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

"Vanja Radovanović"
<elVanja-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote in post
#1110347:
> 
http://stackoverflow.com/questions/16770090/storing-rails-controller-callback-data-in-session
>
> The idea is:
>
>    - Perform some time consuming action in background.
>    - Have the results from that action be propagated back to the
> controller
>    using a callback.
>    - Store the result in an in memory session store.
>    - Have the result in session be used and available from that point
>    onward.
This sounds like a bad idea right out of the gate. My suggestion is to 
put the whole thing out of your mind.

If you have a "time consuming action" then use one of the established 
backgrounding solutions that are available:

https://github.com/resque/resque
https://github.com/collectiveidea/delayed_job

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/8eb8971661ede96e9c32983ea195c260%40ruby-forum.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

Hi, and yes, 
I agree this is not a valid solution for production environments at all.

However, when without many resources, e.g. experimenting, there is no 
"free" option to support such architecture.
E.g. on Heroku you need some funds to have 1 web server and 1 background 
worker.
Also, I really don''t like the idea of setting up such environments in 
development.

Hence, I wanted to see if there way a "cheap and dirty" way of doing
this.
And, to my surprise, session is not being updated as expected.
I also get the feeling there is some important bit of knowledge to be 
gained with deep understanding of this behavior or Rails.

So, I''d still like to know why Rails behaves this way...
Thanks for the input!

On Tuesday, May 28, 2013 3:21:42 PM UTC+2, Ruby-Forum.com User
wrote:
>
> "Vanja Radovanović"
<elV...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <javascript:>> wrote
in post
> #1110347: 
> > 
>
>
http://stackoverflow.com/questions/16770090/storing-rails-controller-callback-data-in-session
> > 
> > The idea is: 
> > 
> >    - Perform some time consuming action in background. 
> >    - Have the results from that action be propagated back to the 
> > controller 
> >    using a callback. 
> >    - Store the result in an in memory session store. 
> >    - Have the result in session be used and available from that point 
> >    onward. 
>
> This sounds like a bad idea right out of the gate. My suggestion is to 
> put the whole thing out of your mind. 
>
> If you have a "time consuming action" then use one of the
established
> backgrounding solutions that are available: 
>
> https://github.com/resque/resque 
> https://github.com/collectiveidea/delayed_job 
>
> -- 
> Posted via http://www.ruby-forum.com/.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/0cc1a791-ed35-4219-a6bd-31e8d31c2929%40googlegroups.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

Checked Rails code, and if I understand correctly, session in fact comes 
from request:

# actionpack-3.2.11/lib/action_controller/metal.rb:132
delegate :session, :to => "@_request" 

It seems session is valid only within request cycle context and although it 
can be accessed, the changes are not saved, as demonstrated by the project.

Hence, your suggestion to use proven techniques is the correct one :-)
Thanks (still glad to have found the reason for above behaviour)!

On Tuesday, May 28, 2013 3:21:42 PM UTC+2, Ruby-Forum.com User
wrote:
>
> "Vanja Radovanović"
<elV...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <javascript:>> wrote
in post
> #1110347: 
> > 
>
>
http://stackoverflow.com/questions/16770090/storing-rails-controller-callback-data-in-session
> > 
> > The idea is: 
> > 
> >    - Perform some time consuming action in background. 
> >    - Have the results from that action be propagated back to the 
> > controller 
> >    using a callback. 
> >    - Store the result in an in memory session store. 
> >    - Have the result in session be used and available from that point 
> >    onward. 
>
> This sounds like a bad idea right out of the gate. My suggestion is to 
> put the whole thing out of your mind. 
>
> If you have a "time consuming action" then use one of the
established
> backgrounding solutions that are available: 
>
> https://github.com/resque/resque 
> https://github.com/collectiveidea/delayed_job 
>
> -- 
> Posted via http://www.ruby-forum.com/.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/9bb17672-900c-4563-94af-ad7251b33353%40googlegroups.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

On Wed, May 29, 2013 at 1:12 AM, Vanja Radovanović
<elVanja-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> It seems session is valid only within request cycle context and although it
> can be accessed, the changes are not saved, as demonstrated by the project.
Uh, no. The whole point of "session" is persisting values across
requests from a given user-agent. And assuredly it does work. If
your example didn''t, there''s some other issue.

-- 
Hassan Schroeder ------------------------
hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
http://about.me/hassanschroeder
twitter: @hassan

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/CACmC4yDyq-tD15_8P8ORT87aYYXJaEEThqK81y9AYP6FawWMEA%40mail.gmail.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

Yeah, that''s the reason I first thought about using it.
But, as the example demonstrates, when I try to adjust the session value 
within a callback (some calculation done in background thread triggers it) 
then the stored value isn''t saved.
Traced the issue to 
http://stackoverflow.com/questions/2139659/access-session-within-rails-controller-thread
and
the fact that background processing is done in a separate thread.
Tried to find a workaround, but it seems to be too much hassle.
If you have an elegant suggestion, I''m all ears :-)


On Wednesday, May 29, 2013 4:51:12 PM UTC+2, Hassan Schroeder
wrote:
>
> On Wed, May 29, 2013 at 1:12 AM, Vanja Radovanović
<elV...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<javascript:>>
> wrote: 
>
> > It seems session is valid only within request cycle context and
although
> it 
> > can be accessed, the changes are not saved, as demonstrated by the 
> project. 
>
> Uh, no. The whole point of "session" is persisting values across 
> requests from a given user-agent. And assuredly it does work. If 
> your example didn''t, there''s some other issue. 
>
> -- 
> Hassan Schroeder ------------------------
hassan.s...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<javascript:>
> http://about.me/hassanschroeder 
> twitter: @hassan 
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/aeeaea43-6e79-450d-ad07-224ccabe59e0%40googlegroups.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.