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?
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
Norm Scherer wrote in post #1102294:
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? --
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.
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.
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?
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
Why hello admin account, how do I love getting it for free 
Colin Law wrote in post #1102465:
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.