Applications, Sessions, and Global.asa

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 else. If we don''t wait long enough then the user might come back and the server might have already deleted all their information and they''d have to start over. Finding the right balance can be difficult and varies from site to site. As a starting point, the default session timeout is 20 minutes. What this means is that after each request the server will wait 20 minutes or until a user comes back before deleting the users information.

Because this is such a hangup for people, I''ll say it again... a session ends 20 minutes after the user''s last request! Not when they close their browser! Not when they go somewhere else! 20 minutes later!

Because of this inefficiency of storing of state after a user has left, many people have resorted to not using sessions at all. While (IMHO) this is a little bit of overkill, it does raise some valid points. First of all, if you decide to use sessions in your site, try and store relatively small amounts of data in them. This also means you should never store actual DB objects or things like that in them! While most people do this expecting to gain speed and save resources by not having to close and reopen the objects, you actually lose performance and eat up more resources! Let MTS (Microsoft Transaction Server) work the way it was meant to and do the pooling for you. Just create and kill the objects on each page as you need them, preferably creating them as late as possible and deleting them as early as possible. (and yes this means you need to close and set to nothing all those ADO objects!)

Applications

Ok so now you know what an ASP session is so what''s an ASP application? Well in general terms an application is basically a program or group of programs designed for end users to use. These include database programs, word processors, spreadsheets, etc. Well on the web we have groups of asp files and to group them together into functional units or a complete program there''s the concept of an application. In the basic sense this is the equivilent of a normal program in that it''s a group of files that work together to perform some purpose. To tie these files together, ASP has an application object.

The application object works similarly to a session object in the sense that you can store variables in it and access it from any page, but it differs in the fact that all users share one application object. So, if one user runs an asp file that changes the value of something of application scope, any future access of it by that user or any other will return the new value. This also means that since the application object isn''t related to any specific user session, it doesn''t have any of the associated problems that session objects do. This makes it a little easier to use and, while you always need to be careful, you''re much less likely to bring a server to it''s knees using the application object then you are using the session object.

The primary purpose of using the application object is to centralize information that is to be used in many places throughout the application. For example, many users store DB connection information there. This allows you to reference the information on any page on which it might be needed and also lets you change it in one place and have that change automatically reflected wherever you use it. It''s still not a great idea to be storing lots of objects in it, but used carefully the application object can be a great asset to almost any web site.

Global.asa

At this point I can almost hear you saying "Okay, so now we know all about sessions and applications, but why is this one file covered in the same article and what the heck does it have to do with all this stuff about user state and global variables?" Well I''ll tell you. It''s often useful to be able to do stuff at the beginning and end of something. For example when you get up in the morning you perform some basic steps to start your day. You take a shower, brush your teeth, get dressed, etc. You do these things so you''re able to function better throughout the day. Well computers work the same way. Before you can expect a session or application to be useful and work it''s best, you essentially need to bring it it''s morning cup of coffee. This is where the Global.asa file comes in.

In the global.asa you can tell the application and session objects what they should do when they start and end. These instructions are placed into what are called event handlers. There are four such event handlers supported in global.asa. They''re named based on their functions so logically enough they are: Application_OnStart, Application_OnEnd, Session_OnStart, and Session_OnEnd. These subroutines can contain most any asp code you want them to with a few exceptions. For example you can''t use Response.Write because since global.asa is never called by a browser it naturally doesn''t return anything to the browser.

I''d like to take this opportunity to drive home the point that Session_OnEnd fires when the session ends and not when the user leaves your site or closes their browser. So by default this happens 20 minutes later and the user is long gone! This is often a source of much confusion for beginners and I thought I should just set the record straight while I had the chance.

In order for the web server to know to look for this file you need to set up your directory as an application in IIS. This is done by navigating to the appropriate web site or directory in Internet Services Manager and right clicking on it and selecting "Properties" from the pop up menu. Then select the "Directory" or "Home Directory" tab and on the bottom half of that window you will see the "Application Settings" section. If it''s not already, you need to make the directory an application by pressing the "Create" button. Click "Ok" to save the setting and exit.

In PWS (Personal Web Server) on Windows 95/98 this is done differently. You need to go to the Personal Web Manager and then click on "Advanced" in the bottom left. In the directory tree you should see an entry named <Home>. Select it and click the "Edit Properties..." button. In the resulting dialog box ensure that all three checkboxes are checked (Read, Execute, and Scripts). Click "Ok" to save the setting and exit. This will enable processing of the global.asa in PWS.

So now that you''ve got an idea what they are and how to use them, you can use applications, sessions, or both in your ASP projects... and you should! While they can be a little confusing and cause problems if you''re not careful, they can also be extremely powerful tools to help you write faster and more efficient ASP.