We looked briefly at what the
and Application
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.Session
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
and Application
work in ASP, we use a single file named Session
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: global.asa
| Physical directory | Virtual directory | Application |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So, when we talk about an application in ASP, we are actually talking about all the files included in the same directory as
, and any of its subdirectories.global.asa
We talked about the events that
and Application
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.Session
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
event is triggered. This is used to initialize any application-wide global variables. When the user begins a session for the first time, the Application_onStart
event is triggered. This is used to initialize user-specific information. Session_onStart
The power of the
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
event. We can force new sessions to always be created as soon as a visitor enters our application by writing code in Session_onStart
to respond to this event. global.asa
When responding to the
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. Application_onStart
and Session
events only happen when a client retrieves an Application
page—they are not triggered when an ASP
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.HTML
The
event occurs either when a current Session_OnEnd
is abandoned by using the Session
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.Abandon
property or by editing the registry. See Chapter 2 for more details. Session.Timeout
Something we need to consider is if we have objects that themselves contain timeouts. If, for example, we create a database connection in a
, 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.Session
The
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 Application_onEnd
event occurred, i.e. when the last session ends and there are no current application users. Session_onEnd