Developing ASP-Based Applications

An ASP-based application consists of a virtual directory on a Web server and all the folders and files within that virtual directory. For more information about virtual directories, refer to your Microsoft Web server online documentation.

An application can be a simple home page; it can include a number of dynamic elements, such as the custom home page of the MSN™ online service (www.msn.com); or it can consist of a complex set of interrelated pages and logic.

When you use ASP-based applications, you are able to maintain state. State is the ability to retain information. You can use ASP to maintain two types of state:

Application state, in which all information pertaining to an application is available to all users of an application.
Session state, in which information is available only to a user of a specific session.

The ASP tools you use to manage state are the Session and Application built-in objects.

Using the Session and Application Objects

You can use the ASP built-in objects Session and Application to extend the functionality of your ASP-based applications.

Use the Session object to manage information for a user when that user is using an application. A session belongs, in effect, to a single user. The Application object is used to store common information that can be shared between all users of a single ASP-based application.

Using the Global.asa File

Each ASP-based application can have one Global.asa file. (The file name extension .asa stands for “Active Server Application.”) This file must be stored in the root directory of the application. ASP reads a Global.asa file when:

The Web server receives the first post-startup request for any .asp file in a given application; that is, after the Web server starts, the first request for any .asp file in an application causes ASP to read the Global.asa file for that application.
A user who does not have a session requests an .asp file in an application.

You can include the following in a Global.asa file:

Application-start events, session-start events, or both.
Application-end events, session-end events, or both.
Object tags. You can use the <OBJECT> tag to create objects in a Global.asa file. Refer to Setting Component Scope for information about creating objects with this tag.

Refer to Global.asa Reference for more information.

Application-Start and Session-Start Events

The application-start and session-start events are Application_OnStart and Session_OnStart, respectively. You should include in these procedures scripts that you want to run whenever an application or session starts. If an application and a session start at the same time, ASP processes the application-start event before it processes the session-start event.

Use the following syntax to define an application-start event:

<SCRIPT LANGUAGE=VBScript RUNAT=Server> 
Sub Application_OnStart
  ' This is where you would insert script for an application-start event.
End Sub
</SCRIPT>

To create an instance of the Ad Rotator component whenever a session starts, you could define the following procedure:

<SCRIPT LANGUAGE=VBScript RUNAT=Server> 
Sub Session_OnStart
  Set Session("MyAd")=Server.CreateObject("MSWC.Adrotator")
End Sub 
</SCRIPT>

Application-End and Session-End Events

The application-end and session-end events are Application_OnEnd and Session_OnEnd, respectively. Like the application-start and session-start events, these events are procedures that you include in a Global.asa file. Unlike start events, end events occur only when a session or application ends; thus, you should include in them any scripts that you want to run at those times. If a session and an application end at the same time, ASP processes the session-end event before it processes the application-end event.

Use the following syntax to define a session-end event:

<SCRIPT LANGUAGE=VBScript RUNAT=Server> 
Sub Session_OnEnd
  ' This is where you would insert script for a session-end event.
End Sub
</SCRIPT>

Use the following syntax to define an application-end event:

<SCRIPT LANGUAGE=VBScript RUNAT=Server> 
Sub Application_OnEnd
   'This is where you insert script for an application ending event.
End Sub 
</SCRIPT>

Ending a Session

A session automatically ends if a user has not requested or refreshed a page in an application for a specified period of time. This value is 20 minutes by default. (Refer to Configuring Registry Entries for information about changing the default value).

You can explicitly end a session with the Abandon method of the Session object. For example, you can provide a Quit button on a form with the ACTION parameter set to the URL of an .asp file that contains the following command.

<% Session.Abandon %>

If, for a specific session, you want to set a timeout interval that is longer than the 20-minute default, you can set the Timeout property of the Session object. For example, the following script sets a timeout interval of 30 minutes.

<%  Session.Timeout = 30  %>

Note You cannot set the timeout interval to be less than the default value.

Ending an Application

An application ends when the Web server is shut down.

Managing Sessions

You can use the Session object to set objects or variables to have session scope. Scope is the extent to which a component instance, object, or variable is available within Active Server Pages. A variable that has session scope, then, is accessible only within that session.

A session can begin in three ways:

A new user requests a URL that identifies an .asp file in an application, and the Global.asa file for that application includes a Session_OnStart procedure.
A user stores a value in the Session object.
A user requests an .asp file in an application, and the application’s Global.asa file uses the <OBJECT> tag to instantiate an object with session scope. See Setting Component Scope for more information about using the <OBJECT> tag to instantiate an object.

SessionID and Cookies

The first time a user requests an .asp file within a given application, ASP generates a SessionID, then sends a response to the user’s browser to create a cookie for the SessionID. The SessionID is a number produced by a complex algorithm that identifies the user’s session. The SessionID cookie is a token sent to a client browser that is not stored on the client computer's hard disk because it does not set an expiration date.

Note While most browsers support cookies, some do not. If a user’s browser does not support cookies, ASP does not support the Session object for that browser.

The SessionID cookie is similar to a locker key in that, as the user interacts with an application during a session, ASP can store information for the user in a “locker” on the server. The user’s SessionID cookie, which it sends in the HTTP request header, enables access to this information in the way that a locker key enables access to a locker’s contents. Each time that ASP receives a request for a page, it checks the HTTP request header for a SessionID cookie.

Storing Variables in the Session Object

You need only reference a new variable in order to create and store the variable in the Session object. For example, the following commands store three new variables in the Session object:

<% 
Session("Initiated") = Now 
Session("Fidelity") = "Low" 
Set Session("myObj") = Server.CreateObject("someObj") 
%>

Remembering User Preferences

You can store user preferences in the Session object. For example, you can allow a user to specify a text-only version of your content in the first page of the application and apply this choice on all subsequent pages that the user visits in this application.

<%If Session("Fidelity") = "Low" Then %> 
This is the text version of the page.
<% Else %> 
This is the multimedia version of the page.
<% End If %>

Managing Applications

You can use the Application object to set properties that are accessible to every user in an ASP-based application.

Posting Messages to Application Users

You can use the Application object to post a message that each user of the application sees on entering the application. This section shows an example in which you define an application property called message in an Application_OnStart procedure, then enable subsequent users to modify the message.

The application-wide message is given a default value in Global.asa:

<SCRIPT LANGUAGE=VBScript RUNAT=Server> 
Sub Application_OnStart
  Application("Message") = "This is the default message." 
End Sub
</SCRIPT>

A.asp displays the message. Every user who requests A.asp can see the global message.

<HTML> 
<BODY>
This is the message: <p> 
<%= Application("Message") %>
</BODY>
</HTML>

B.asp provides a way for a user to type a new message and submit the change.

<HTML> 
<BODY>
<form method="post" action="C.asp"> 
Enter a new value for the application-wide message:<BR> 
<input type="text" name="newmsg" size=60><p> 
<input type="submit" value="Submit"> 
</form> 
</BODY>
</HTML>

C.asp resets the global message to the value received from a user in B.asp and redirects the user to A.asp to see the new value.

<% 
If Not IsEmpty(Request.Form("newmsg")) Then 
  Application.Lock
    Application("Message") = Request.Form("newmsg") 
  Application.Unlock
End If 
Response.Redirect("A.asp") 
%>

Setting Component Scope

An ASP-based application can set ActiveX server components to have application, session or page scope.

An application-scope component instance is a single instance of a component that is created when the application starts. This instance is shared by all client requests.
A session-scope component instance is created for each new session in an application and released when the session ends; thus, there is one instance per active session.
A page-scope component instance is created for the processing of a page for one client; it is available through the processing of that page; and is then released when the response is sent back to the client. A component instance has page scope by default.

You can use either the <OBJECT> tag in a Global.asa file or the Server.CreateObject method to store instances of ActiveX server components in Session and Application objects.

Using the <OBJECT> Tag

You can declare component instances with session or application scope in a Global.asa file by using the <OBJECT> tag, extended with RUNAT attribute (which must be set to Server) and SCOPE attribute (which can be set to Session or Application). You can accomplish this by using either the registered name (PROGID) method or the registered number (CLASSID) method.

The following example uses the registered name (PROGID) method to create a session-scope instance of the Ad Rotator Component:

<OBJECT RUNAT=Server SCOPE=Session ID=MyAd PROGID="MSWC.Adrotator">
</OBJECT>

The following uses the registered number (CLASSID) method to create an application-scope instance of the Ad Rotator Component:

<OBJECT RUNAT=Server SCOPE=Application ID=MyAd 
CLASSID="Clsid:00000293-0000-0010-8000-00AA006D2EA4"></OBJECT>

When you declare a session-scope or application-scope instance of a component by using the <OBJECT> tag, the variable you assign to the component goes into the session or application namespace, respectively. This means that you do not need to use the Session or Application built-in objects to access the component instance. For example, the following script command, issued from within any .asp file that is part of the application containing the examples shown above, would open the instance of the Ad Rotator component declared in those examples:

<%= MyAd.GetAdvertisement("addata.txt") %>

You can also use the <OBJECT> tag to create ActiveX server component instances in a particular .asp file. In this case the SCOPE attribute can be omitted, or set to PAGE. All such component instances have page scope.

Using the Server.CreateObject Method

You can use the Server.CreateObject method to store an instance of a component in the Session object. The following example stores an instance of the Ad Rotator component in the Session object.

<% Set Session("MyAd") = Server.CreateObject("MSWC.Adrotator") %>

To display an ad, you would include the following:

<% Set MyAd = Session("MyAd") %> 
<%= MyAd.GetAdvertisement("addata.txt") %>

Performance Issues

ASP does not instantiate a component that you declare with the <OBJECT> tag until that component is referenced by a script command from an .asp file. The Server.CreateObject method instantiates the component immediately. Thus, the <OBJECT> tag offers better performance than the Server.CreateObject method for session-scope components.

For creating page-scope components, the <OBJECT> tag and the Server.CreateObject method offer equivalent performance.

You can use the <OBJECT> tag to store single-threaded, free-threaded, or apartment-threaded objects in both the Session and the Application objects. You can use the Server.CreateObject method to store single-threaded, free-threaded, and apartment-threaded objects in the Session object. However, whether you use the <OBJECT> tag or the Server.CreateObject method, unless the object you store is marked “both,” ASP treats the application or session containing this object as “single-threaded.” Thus, storing objects that are not marked “both” may have performance implications, particularly for high-volume sites. Refer to Creating Components for ASP for more information on threading models.