storing values in session variable vs instance variable

[John Merlino]

Is there a good practice when to use the session variable. Sometimes I find myself using both the session variable and instance variable. For example, I have a table that allows a user to select a date. I store the date both in the session and in the instance variable. Should I not bother to store it in session? In what situations should you use the session variable?

[Norm Scherer]

> the session variable? --
The rails session persists across requests while instance variables do
not. If you need something in a following request it (or a reference)
must be in the session. If you do not need it later I always use an
instance variable.

Norm

[Robert Walker]

Norm Scherer wrote in post #1102294:

I wouldn't say that this is precisely accurate. You could continue
passing a variable from one request to another, and to third, and so on.

Session variables are useful when you really need a value to persist for
the entire session. I would also say that it's good practice to use
session variable sparingly. Session variables are somewhat akin to
global variables in the sense that they represent globally accessible
shared state (at least within the context of the current session).

Session variables are also long lived, taking up memory as long as the
session is kept alive. Although in a Rails application sessions are torn
down and recreate upon every request, but that might even be worse than
just leaving them in memory between requests.

Another thing to keep in mind is that by default Rails uses a cookie
based session storage mechanism, which means sessions have a hard 4K
limit (cookies are limited to 4K by spec). Another reason to avoid
putting large amounts of data in the session.

A typical use case for session variable are things like the "id" of the
current user. Notice I said the "id" not the user object itself. It's
better to load the user object when, and only when, necessary. There are
other great uses for session variables, but think twice about if it's
really necessary and try to keep the amount of data as small as
possible. Remember for every variable in the session is just one more
thing that has to be loaded from persistent storage on every single
request.

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

[John Merlino]

instance variables are alive as long as the object instance is alive. My question then would be from one http request to the next does the same controller instance remain alive? If so, then there's no need for sessions at all. Right?

[Colin Law]

On 20 March 2013 15:41, John Merlino <stoi...@aol.com> wrote:
> instance variables are alive as long as the object instance is alive. My
> question then would be from one http request to the next does the same
> controller instance remain alive?

No. In addition, once you deploy, you cannot even assume that the
server is still running. Many systems will shut down the server if it
is idle and re-start it when required. Also remember that if user A
makes a request then is it common that user B may make a request
before the next request from user A. So even if the same controller
instance did stay alive the data for the two users would get mixed up.
Sessions get around this problem.

Colin

> --
> 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-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyonrails-talk/-/WjlpqhZwf88J.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jordon Bedwell]

On Wed, Mar 20, 2013 at 10:48 AM, Colin Law <cla...@googlemail.com> wrote:
> On 20 March 2013 15:41, John Merlino <stoi...@aol.com> wrote:
>> instance variables are alive as long as the object instance is alive. My
>> question then would be from one http request to the next does the same
>> controller instance remain alive?
>
> No. In addition, once you deploy, you cannot even assume that the
> server is still running. Many systems will shut down the server if it
> is idle and re-start it when required. Also remember that if user A
> makes a request then is it common that user B may make a request
> before the next request from user A. So even if the same controller
> instance did stay alive the data for the two users would get mixed up.
> Sessions get around this problem.

Why hello admin account, how do I love getting it for free :D

[Robert Walker]

Colin Law wrote in post #1102465:

> On 20 March 2013 15:41, John Merlino <stoi...@aol.com> wrote:
>> instance variables are alive as long as the object instance is alive. My
>> question then would be from one http request to the next does the same
>> controller instance remain alive?
>
> No. In addition, once you deploy, you cannot even assume that the
> server is still running. Many systems will shut down the server if it
> is idle and re-start it when required. Also remember that if user A
> makes a request then is it common that user B may make a request
> before the next request from user A. So even if the same controller
> instance did stay alive the data for the two users would get mixed up.
> Sessions get around this problem.

And even worse than this if you have multiple severs the request #1 from
user A may go to server #1 and request #2 may go to server #2. If
controllers remained alive between request then values stored in
instances variable on server #1 would not be available on server #2.

In Rails sessions are also "persisted" across servers and application
instances. As I mentioned before sessions are torn down (persisted
somewhere) and reloaded between every request. It makes not difference
which instances or server you're hitting The session is available
everywhere. There are many options on where to persist session data.
Cookies (the default), ActiveRecord, Memcachd, etc. In all these cases
session data must be available to any instance or server wishing to
access that shared session state.