Storing Rails controller callback data in session

[Vanja Radovanović]

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.

[Robert Walker]

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

[Vanja Radovanović]

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!

[Vanja Radovanović]

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:

[Hassan Schroeder]

On Wed, May 29, 2013 at 1:12 AM, Vanja Radovanović <elV...@gmail.com> 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...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

[Vanja Radovanović]

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