application|session
One of the things that most new ASP users find confusing is the concept of Sessions and Applications. Add to this the fact that there's this special file on the web server called global.asa that is somehow related (and yet can't be requested via a browser) and it makes for a very confusing situation indeed. That's why I'm writing this article. This isn't going to be a comprehensive discussion of everything you can do using Sessions, Applications, and the Global.asa, but is instead meant as an introductory level overview to try and alleviate some of the confusion and misconceptions associated with these topics.
Sessions
Of the topics I'm covering, people usually have the easiest time with the concept of a session so I'll cover it first. This probably stems from the fact that almost all computing used to be done this way. You'd log on, do what you needed to do and then log off. In fact most programs still work that way. For example when you start Windows the first thing you is log in. Then you do what you have to do and when your done you log off. Similarly, when you need to do something in an application, you open the application, do what you want to do and then close it. This scenario is similar to a session, but when it comes to the web there is one problem... the protocol of the web (HTTP) doesn't maintain state. This is like using a word proccessor that with every word you type forgets what document it belongs in or even that it's you typing it!
So if no state is maintained then the web server doesn't know who you are, if you're still reading the content it gave you, or even if you're already long gone. It really doesn't care and if you think about it, the concept really does make sense for static pages. If you're just publishing a document for everyone to see, what difference does it make who you are or what you've already done if you're going to get the same page as everyone else anyway? So the question then becomes, why should the server waste the resources needed to track users and maintain their information between requests? Well as you'd expect (or at least infer from my rambling on about it) the web server doesn't!
Now along comes ASP and suddenly we're not serving static pages anymore. Some people get one thing and others get something entirely different. And not just that... we want to let a user do things that might take more that one request. So what are we supposed to do... make the user tell us who they are and everything about themselves with every request? Well that would certainly make our lives easier, but I don't think visitors to your web site would like it very much!
So, as always seems to happen when we have a problem like this, ASP comes to our rescue and maintains state for us. It does this by creating a unique cookie and sending it to the client. This cookie then acts as an identifier so that the server knows which set of session information on the server is associated with which requests. So it's important to note that while all information in a session is actually stored on the server and not transmitted to the browser, the fact remains that cookies need to be enabled in order for the server to track a users session. Using this combination of server side storage and cookies, ASP provides us with a nice neat way to use this information without having to worry about how it's actually done. This interface is called the Session object.
While the Session object does have some useful properties and methods, the most important thing about it is that you can place variables in it and it will maintain them for you until the session ends. For example:
Session("FirstName") = "John"
will set the Session variable FirstName to John (which if you couldn't guess is my first name). Now that I've stored the value in a session variable I can access it on any subsequent page by simply using:
Session("FirstName")
Except for the fact that it doesn't go away when the page is done executing, it behaves the same as any other variable in ASP and can be used in the same manner.
Those of you who were paying attention probably caught that I mentioned that these variable are only good until the session ends and yet I didn't tell you when that happens. This is the main problem with sessions and why they've gotten such a bad reputation. You see, since we don't know if a users going to come back or not (because of the stateless nature of HTTP) we don't know how long to keep their session alive. Until the next request, we never know if the last one was their final one or if they're going to be right back. This leaves us with somewhat of a dilemma. If we wait too long then we're storing all the users information and using up resources on the server that could almost certainly be better used for something el