Classic ASP Application and Session

In classic ASP platform, Application and Session objects are used to manipulate all application and session matters accordingly. Both Application and Session objects are not page-specific objects but rather in a more global sense. A Session is a global concept for a particular user during visiting an IIS server. An Application is a global concept for an ASP application of an IIS server and is common to all visiting users. In other words, a Application object is not page- and user specific object.

Application and Session Object Features

The features of Application and Session Objects are

	Application	Session
Method	Contents.Remove	Abandon
	Contents.RemoveAll	Contents.Remove
	Lock	Contents.RemoveAll
	Unlock
Property	Contents	CodePage
	StaticObjects	Contents
		LCID
		SessionID
		StaticObjects
		Timeout
Event	Application_OnEnd	Session_OnEnd
	Application_OnStart	Session_OnStart

Variable

One of the key features of Application and Session objects are used to store values that are used as global variables rather than page-specific for either a particular user (the Session) or to all users (the Application). The Session and Application variables are stored on the server. Client browsers are then attached to the session through a cookie. As a result, the client must have cookies enabled in the browser for Session and Application variables to work.

Session variable

The power of the Session object comes from the fact that it can store variables that are global to just that specific user; as a result, each user can have their own individual value for that variable. Session objects are not always created automatically for every user when they enter your application. However, storing or accessing a variable in the Session object creates the Session object and fires the Session_OnStart event.

Application variable

Think of the Application object as a global container for information that is available to all pages of an ASP application. Both variables and object references can be stored in the Application object. The Application object is instantiated when the first page of the application is requested and remains available until the Web service is shut down.

Event

Event is another key features of Application and Sessions

Application_OnStart and Session_OnStart events

Both the Application_OnStart and Session_OnStart events can be used to initialize state. To do this, set up variables that are global for either the application or a specific user. When the first user accesses a file in an application, the Application_OnStart event is triggered. This event 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 event is used to initialize user-specific information.

Application_OnEnd and Session_OnEnd events

The Session_OnEnd event occurs either when a current session times out. By default, this is 20 minutes after the last request for a page from the application. This default time out setting can be changed by setting the Session.Timeout property or editing the registry. The Application_OnEnd event can be used to clean up all of the global objects and variables. However, in a present problem, this event may not 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 occurs, that is, when the last session ends and there are no current application users.

Global.asa File

The file with file name Global.asa must be stored in the root directory of an application. An application can only have one Global.asa file. In general, the Global.asa file is an optional file for specifying event scripts and declaring objects that have session or application scope of the application in which the Global.asa file is stored.

Global.asa files can contain only the following:

• ASP Built-in Object Events (one each of Application_OnStart, Application_OnEnd, Session_OnStart, and Session_OnEnd)
• OBJECT Declarations
• TypeLibrary Declarations

If the included script is not enclosed by <SCRIPT> tags or the defined object does not have session or application scope, the server returns an error. The server ignores both tagged script that the application or session events do not use, as well as any HTML in the file.

The scripts contained in the Global.asa file may be written in any supported scripting language. If multiple event or object scripts use the same scripting language, they can be combined inside a single set of <SCRIPT> tags.

When changes to the Global.asa file are saved, the server finishes processing all of the current application requests before it recompiles the Global.asa file. During that time, the server refuses additional requests and returns an error message stating that the request cannot be processed while the application is being restarted.

After all of the current user requests have been processed, the server deletes all active sessions, calling the Session_OnEnd event for each session it deletes, closes the application, and calls the Application_OnEnd event. The Global.asa file is then recompiled. Subsequent user requests will start the application and create new sessions, and trigger the Application_OnStart and Session_OnStart events.

Procedures declared in the Global.asa file can be called only from one or more of the scripts associated with the Application_OnStart, Application_OnEnd, Session_OnStart, and Session_OnEnd events. They are not available to the ASP pages in the ASP-based application.

To share procedures across an application, the procedures can be declared in a separate ASP file, and then use Server.Transfer Method and Server.Execute Method. Besides, server-side include (SSI) statements can also be used to include the file in the ASP pages that call the procedures.

Remarks

Application and Session variables require that clients have cookies enabled in their Web browser, which is not reliable between shared frames in a frameset or across multiple browser instances. Session and Application events are only triggered 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 Internet Server Application Programming Interface (ISAPI) or Common Gateway Interface (CGI) scripts, make sure that these applications do not depend on specific events having occurred within an ASP page. Otherwise, the ISAPI or CGI script may fail (crash) and cause the Web server to stop responding (hang). This method stores information on the Web server. This decreases scalability in two ways: Session and Application variables use resources on the server and cannot be used on completely load balanced Web Farms.

References

• Avoiding traps when using the Application and Session objects http://msdn.microsoft.com/library/periodic/period00/asp1100.htm
• Cookies http://msdn.microsoft.com/library/psdk/iisref/vbob87j9.htm
• Using variables and constants http://www.microsoft.com/windows/windows2000/en/datacenter/iis/htm/asp/iiwavar.htm
• Active Server Pages guide http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/iisbook/c06_active_server_pages.mspx?mfr=true
• ASP scripting optimization http://www.microsoft.com/windows/windows2000/en/advanced/iis/htm/asp/perf9ini.htm
• 281298 PRB: Session variables do not persist when application contains empty Global.asa
• 230149 How to access Session and Application variables from within a Visual Basic component
• https://support.microsoft.com/en-us/help/300883/how-to-use-session-and-application-variables-in-an-asp-program
• https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525316(v=vs.90)