Storing Rails controller callback data in session

Rails
1

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:

Any input appreciated.

2

“Vanja Radovanović” [email protected] wrote in post #1110347:

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:

3

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!

4

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 :slight_smile:
Thanks (still glad to have found the reason for above behaviour)!

5

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

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 :slight_smile:

6

On Wed, May 29, 2013 at 1:12 AM, Vanja Radovanović [email protected]
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 S. ------------------------ [email protected]

twitter: @hassan