I know that there have been a lot of articles written on Session variables, and there are a number about them on this site. So, you may be wondering, why am I writing yet another article? The reason is because far too many people still use Session variables far too liberally. Session variables are evil; Session variables will hurt you and your loved ones.
Session variables are a lot like drugs. There are a number of informational articles that say, "Don't use Session variables," much the same as we bombard our elementary students with the "Just say no" philosophy. However, Session variables are alluring and many developers are tempted to use them. Like drugs, when a developer starts using Session variables, he usually uses them in wise moderation. With such prude use, there is only a minimal degredation in performance. The ease of using these damned variables, though, encourages the developer to use them more and more often, and before you know it, this developer is hooked- he's become a Session variable junkie.
There are four types of people: those who don't know about the harms of Session variables; those who know about Session variables and avoid them at all costs; those who know about Session variables disadvantages, but still use Session variables in moderation; and, finally, there are Session variables addicts. What category do you fall into? Below you'll find some advice for each of the four categories.
The "What are Session Variables?" Crowd:
Session variables are equivalent to global variables in VisualBasic, except that each visitor to your site gets his or her own "set" of session variables. Session variables are variants, meaning that they can store anything, from strings to integers, to large ADO objects. Session variables are useful at times because they make information passing very simple. They are bad because they really can hurt a site's performance, especially if you store large objects in session variables. There is a good article on 4Guys titled Pros & Cons of Session Variables. You should read this. You may be wondering if Session variables are a thing to use or to avoid like the plague. Well, try your best to avoid them, although responsible use of Session variables is acceptable.
Those who avoid Session variables at all costs:
Congradulations! You are to be commended for your strict lack of Session variable usage. I trust you have perfected the art of passing variables through the QueryString and through POSTed FORMs. One question, though: "Are you letting IIS know that you don't want to use Session variables?" See, even if you don't use Session variables at all, IIS still prepares for their usage. You can inform IIS that it need not worry about this by setting the
@ENABLESESSIONSTATE variable. Read Using
for more information.
Those who use Session variables Prudently:
I can empathize with you guys. While I try to avoid Session variables earnestly, I do use them when needed. I just strongly advise that you make sure you leave all objects out of the Session variable scope. There's a great article on ActiveServerPages.com explaining why you want to keep objects out of Session variable scope. If you find yourself placing ADO objects into Session variables, then you, my fried, are close to becoming a full-blown Session junkie! Get help!
The best way to stop using Session variables is to do it cold turkey. Just quit! You may be used to not having to pass around data between your ASP pages, but it's really not that difficult. Read up on Joao Vieira's Four Ways to Pass Information from One ASP Page to Another. Of course, Joao mentions the use of Session variables as one way to pass information: don't do this!! <g>
I hope this FAQ has helped you realized how evil Session variables are, and why you shouldn't use them. Have a great day!