Storing Rails controller callback data in session

rubyonrails-talk
1

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 actions
def on_counter_value_calculated(context, new_value)
  @counter = new_value
session[:counter] = @counter
end

However, stored session is lost in subsequent calls.

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

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

Any input appreciated.

2

"Vanja Radovanović" <elVanja@gmail.com> 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

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.

6

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