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.
Well that's about all I've got to say on the topic. If you feel I've
left anything out or would like me to clarify anything, please let
me know and I'll do my best to
address your concerns. Oh and just in case you want some more info:
Related Information
Counting Active Users - An article describing a use of sessions, applications, and global.asa ASP Object Model - Documentation of the objects' collections, properties, and methods
