display | more...

ASP Application Object

The Application object represents an ASP-based application. (An ASP-based application is defined as all of the .asp files in a virtual directory and it's subdirectories.) It shares, stores, and retrieves information in response to requests from users to the application. This information is global (shared over all user sessions). In ASP, this is also known as "application scope" information.

Adding and retrieving information with the Application object (VBScript):

  Application("A_String") = "String variable"
  Application("Sum") = 5 * 5
  Set Application("FileSystemObject") = Server.CreateObject("Scripting.FileSystemObject")

  my_string = Application("A_String")
  'my_string is now equal to "String variable"

  my_sum = Application("Sum")
  'my_sum is now equal to 25

  Set fso = Application("FileSystemObject")
  'fso is now a FileSystemObject object
  'Application.Contents("A_String") == Application("A_String")
  'Application(key) is a shortcut for Application.Contents(key).


Contents Collection
A collection of all of the items which have been created and added to the Application object during client sessions through script commands, such as the Server.CreateObject, rather than by using the HTML <OBJECT> tag.

StaticObjects Collection
A collection of all of the items which have been created and added to the Application object during client sessions by using the HTML <OBJECT> tag, rather than using script commands.


Contents.Remove Method (v 3.0)
The Contents.Remove method is used to remove a single item from a Contents collection.

Contents.RemoveAll Method (v 3.0)
The Contents.RemoveAll method is used to remove all items from a Contents collection.

Lock Method
The Lock method prevents all other users from making changes in the Application object. Since the Application object can be shared by more then one user, the Lock method is provided to ensure that multiple users cannot alter a property simultaneously (see synchronization).

Unlock Method
The Unlock method allows any user to have access to any of the Application object properties in order to make changes.


OnEnd Event
The OnEnd event occurs when the Application quits. This should not occur unless all user sessions are over. The signal of this event will run a handler script in the Global.asa file, if the script exists. This is a good time to remove all of the contents of the Application object to release memory.

Example of a OnEnd handler function. This script will remove all information from the Application object, and free the memory it was using.

  <script language="vbscript" runat="server">
    Sub Application_OnEnd
    End Sub

OnStart Event
The OnStart event can occur at two times.
1) The first time a new user session is started.
2) Any time a new user session is started after the OnEnd event is generated.
The signal of this event will run a handler script in the Global.asa file, if the script exists.

Example OnStart handler script. This script initializes a Application scope counter, which can be used to count the number of visitors since the last time the application was restarted.

  <script language="vbscript" runat="server">
    Sub Application_OnStart
      Application("VisitorCount") = 0
    End Sub

Tips & Hints

Large Arrays & Application Objects
Storing large arrays in Application or Session objects is a bad idea. The semantics of most scripting languages require that before you can access any element of the array, a temporary copy of the entire array must be made. This effectively uses up twice the memory to store the array. Generally, this isn't something you want to do.

Application Level Components?
You'd like that COM/COM+ object you just wrote to be available across all of your user's sessions? Think that creating one global reference of the component will improve performance (by not having to create and destroy the object on individual pages)? In most cases, placing a component in the Application object will degrade performance, not increase it. Why?

ASP maintains a pool of worker threads that service requests. Normally, the request is handled by the first available thread. However, ASP must create a special thread to run non-agile1, Application scoped components. What this means is that all calls to this component must now use this special thread and all calls are serialized. So instead of using the first available thread, every call to this component must wait on one unique thread. As load increases (and the component is called more frequently), this will kill performance.

Back to ASP Objects

1ASP components can be classified as "agile" and "non-agile" components. The difference is in the way they handle thread synchronization. Most components fall into the "non-agile" category.


All code is my own (but it can be yours for 3 easy payments of $29.95!)

(v 3.0) indicates that this feature is only available with ASP Version 3.0, which shipped standard with IIS 5.0