Article
ASP Sessions and Applications
The Application Object
Whereas every page request gets its own Request and Response objects, all requests for ASP pages in a Web application share the same Application object. This object is created the first time an ASP page is requested from the application after the Web server starts up, and is destroyed when the Web server shuts down, or when the Web application is unloaded manually in the IIS management console. Because this object persists from one page request to another, it can be used to store data that you want to share with all other pages in your application.
To store a value in the application object, simply use the following syntax:
Application("varName") = value
You can then access that stored value as you would a regular variable, except as Application("varName"). A simple use of the Application object would be for a hit counter. You could record the number of hits your Website has received as Application("hits"), and increment that value with each page request. Here's the basic code involved:
1 <% Option Explicit %>
2 <html>
3 <head>
4 <title> Simple counter </title>
5 </head>
6 <body>
7 <p>Page requests: <%
8 Application("hits") = Application("hits") + 1
9 Response.Write(Application("hits"))
10 %></p>
11 </body>
12 </html>
Line 8 adds 1 to the value of Application("hits"), and line 9 then prints out the updated value. Save the above code in an ASP file (e.g. counter.asp) in your application directory, and then load it repeatedly into your browser (e.g. http://localhost/myapp/counter.asp). Watch as the count increases by 1 with each page request. By including this code fragment on each page of your site, you can count the total number of page requests, as all of your pages will share the same Application("hits") value.
While the above method of value storage and retrieval represents the way you'll use the Application object 90% of the time, this object does have a few more methods you should be aware of.
First of all, Application("hits") is actually just a shortcut. The hits variable is actually a member of a collection called Contents, which is a property of Applications. Thus, the longhand version is Application.Contents("hits"). There's no reason for you to use this longer version when accessing stored values, but you must use it when you remove a stored value from the application. To do this, call the Remove method of the Contents collection, as follows:
Application.Contents.Remove("hits")
This code would delete the "hits" stored value from the application. To remove all stored values from the application, you can use the RemoveAll method:
Application.Contents.RemoveAll
To understand the purpose of the remaining two methods of the Application object, Lock and Unlock, we must first take a close look at Line 8 from the hit counter example above:
8 Application("hits") = Application("hits") + 1
As you can see, this line actually accesses the stored application value twice. The first time (on the right of the equals sign), it retrieves the stored value. Then, after adding 1 to the retrieved value, it accesses the stored value a second time (on the left of the equals sign) to record the updated value over the top of the existing value.
What's important to understand is that the three steps described above do not necessarily occur as an uninterrupted sequence of events. If two Web browsers were to access your site at the same time, the events for each browser could intermingle, producing a sequence like this:
If you look at this sequence closely, you'll realize that the two hits that should have been recorded only resulted in an increase of 1 to the stored "hit" value! To avoid this happening, your code should "lock" the Application object before undertaking a series of events like this that should occur in an uninterrupted sequence. Thus, Line 8 above should be replaced with these three lines:
8 Application.Lock
9 Application("hits") = Application("hits") + 1
10 Application.Unlock
The call to Application.Lock on Line 8 waits for any other processes to finish accessing the Application object, before locking access to it. This forces other clients to wait until the call to Application.Unlock on Line 10 before they can read or write the stored values again. This effectively prevents the occurrence of mix-ups like the one above, as 'browser 2' would have to wait for 'browser 1' to read and then store its updated value before it could read the value and update it itself.