We looked briefly at what the Application and Session object are in Part 1 of this book, and had a brief glimpse of the way they could be used. When we come to build Web-based client/server applications, these two objects assume a far greater importance that we’ve previously credited them with. They allow us to connect together all the parts of our application.
For example, we can tell where on our site our visitor has already been, where they need to go next, and what they've decided to buy as they go along. In other words we can store and maintain the values of variables for each user, as well as globally for all users. In this section, we'll explore some of the possibilities in detail.
To make Application and Session work in ASP, we use a single file named global.asa for each 'application'. This file resides in the directory on the server that is the root of that application—i.e. where the files that make up the application are located. Any subdirectories of the main application directory are also part of the application, and the global.asa file applies to their contents as well. This means that you need to be aware of the possibility of overlap between applications, and should generally create separate directories for each one. For example:
| Physical directory | Virtual directory | Application |
C:\InetPub\WWWRoot\ |
/ |
|
C:\InetPub\WWWRoot\Demo\ |
/DemoApp |
Demo |
C:\InetPub\WWWRoot\Demo\Images\ |
Demo |
|
C:\InetPub\WWWRoot\Apps\Main\ |
/MainApp |
MainApp |
C:\InetPub\WWWRoot\Apps\Main\Test\ |
/TestApp |
TestApp and MainApp |
So, when we talk about an application in ASP, we are actually talking about all the files included in the same directory as global.asa, and any of its subdirectories.
We talked about the events that Application and Session implement back in Chapter 2. However, we'll summarize these briefly in the context of state, and then quickly move on to look at how we can use them in our applications.
Both of these events are to be used to initialize state, by setting up variable that are global either for the application or a specific user. When the first user accesses a file in our application, the Application_onStart event is triggered. This is used to initialize any application-wide global variables. When the user begins a session for the first time, the Session_onStart event is triggered. This is used to initialize user-specific information.
The power of the Session object comes from the fact that it can store variables that are global to just that specific user, and so each user can have their own individual value for that variable. Session objects are not always created automatically for every user when they enter our application. However, storing or accessing a variable in the Session object will create it, and fire the Session_onStart event. We can force new sessions to always be created as soon as a visitor enters our application by writing code in global.asa to respond to this event.
When responding to the Application_onStart event, we must not under any circumstances use code specific to any one particular user. In this event we would typically create global objects, such as a server side component that needs to be shared and available to every visitor.
Session and Application events only happen when a client retrieves an ASP page—they are not triggered when an HTML page in the application is requested. Therefore, if you have additional server side applications such as ISAPI or CGI scripts, make sure that they do not depend on specific events having occurred within an ASP page. Otherwise the ISAPI or CGI script may crash and cause the Web server to hang.
The Session_OnEnd event occurs either when a current Session is abandoned by using the Session.Abandon method, or when it times out. By default this is 20 minutes after the last request for a page from the application, though this can be changed either by setting the Session.Timeout property or by editing the registry. See Chapter 2 for more details.
Something we need to consider is if we have objects that themselves contain timeouts. If, for example, we create a database connection in a Session, and the connection timeout is less than the Session timeout, it's possible for corruption of the object to occur. If the database connection times out after ten minutes, and the Session times out after twenty minutes, the database connection will not be valid, even though the object in the Session still is.
The Application_onEnd event can be used to clean up all of the global objects and variables. There is a problem at the present time, however, in that this event may not actually be triggered until the Web server is stopped. Revisions of ASP seem likely to specify that the Application_onEnd event be triggered once the last Session_onEnd event occurred, i.e. when the last session ends and there are no current application users.