Storing State in Objects

See Also

One of the easiest ways to store state information for an IIS application is to store it in an object. When you store state in an object, you use properties or variables within the object to hold the information you want to retrieve. There are several approaches you can take to use objects in this way for your IIS applications:

Regardless of which approach you use, you write code in your webclass that writes information to the appropriate object upon receiving a request, retrieves information as necessary from the objects, and manipulates the stored state information.

Note   If your webclass is set to stay alive between requests, the end user must have a browser that supports cookies and cookies must be enabled. For more information, see "State Management in IIS Applications."

Storing State in the WebClass Object

Normally, the webclass run time creates an instance of the webclass each time a request is made, then destroys it after the response has been sent to the browser. However, you can use a webclass property called StateManagement to alter this behavior.

Using StateManagement, you can keep the instance of the webclass instantiated, or alive, between requests. If you choose to keep the webclass alive between requests, the run-time DLL instantiates the webclass when the first request occurs and does not destroy it until the application terminates. This enables you to use variables within the webclass to store some information between browser requests. However, this solution will affect the scalability of your application because webclasses that stay alive are stored in the Active Server Pages Session object. As a result, subsequent requests must be routed to the same Web server and the ASP must take actions to ensure that the correct thread is used to process the request.

Note   You can use the ReleaseInstance method to terminate an instance of a webclass you have kept alive across requests. When you use this method in a procedure, the run-time DLL terminates the instance of the webclass at the end of the procedure.

If you choose not to keep the webclass alive, the run-time DLL creates and destroys the webclass for each request. You can still maintain state information if you select this option, but you cannot store it in the WebClass object. Instead, you need to use other methods to maintain your state. Some of these methods include using objects, databases, cookies, or the URLData property to manage your state.

To keep the webclass alive across requests

To terminate an instance of a webclass you have previously kept alive

Storing State in the Session Object

You can use the Session object to maintain state information about a single webclass user. The Session object is part of the Active Server Pages object model and is treated as a property of the WebClass objects in your IIS application.

Note   Using this method does not require you to set the webclass's StateManagement property to wcRetainInstance — you can store state in the Session object even if your webclass is set to store no state.

Both the Session object and the WebClass object allow you to store state on the webclass level in session-specific, server-side state. However, storing information directly in the Session object rather than that WebClass object allows you to share state with other webclasses or Active Server Pages. In addition, Visual Basic objects (such as the WebClass object) are apartment-threaded and bind all requests to a particular thread in IIS, so using the Session object is more optimal.

Suppose you want to ensure that a user in your application sees a page called CustomerInfo only once. The following code shows how you can set a Session object property during processing to record the fact that the user has seen this page:

Sub CustomerInfoForm_Submit
   
   'Code to process the form here
   
   'Set the value of the session variable accordingly.
   Session("CustomerInfoDisplayed") = True
   
End Sub

This code sets the value of a Session object variable to True when the user clicks a button on the CustomerInfo page. This tells the webclass that the user has been to the page in question.

Once that information is recorded, the webclass must use this information to make processing decisions. The following code shows how the webclass accesses the Session object property to determine whether or not to display the customer information form at another critical point in the application:

Sub PlaceOrder_Click

   'If the session variable is not set then customer info
   'page has not yet been displayed, so return it to the user

   If Session("CustomerInfoDisplayed")= "" Then
      Set NextItem = CustomerInfoForm
   Else
      Set NextItem = OrderForm
   EndIf
End Sub

In this code, the webclass checks a Session object property to see whether the customer information page has already been displayed. If so, it displays the order form. If not, it displays the customer information.

Storing State in the Application Object

You can use the Active Server Pages Application object to maintain state information about one or more users for the webclass. The Application object is part of the Active Server Pages object model, and is treated as a property of the WebClass objects in your IIS application. This object allows you to track more information than can be recorded in the Session object.

Suppose you want to count the number of times all users in your application access a certain page. The following code shows an event procedure you would use to store this count in the Active Server Pages Application object:

Private Sub MyWebclass_Start

   'Create a variable to store the number of users
   Dim Counter as Long

   'Temporarily lock the application, then increment
   'the count by one.
   Application.Lock
   Counter = Application("MyWebClassAccessCounter")
   Counter = Counter + 1

   'Store the value
   Application("MyWebClassAccessCounter") = Counter
   
   'Unlock the application
   Application.Unlock
   
   'Begin the application
   Set NextItem = WebItem1

End Sub