Using XML to Maintain Client State in ASP

Originally Published 8/23/2000 on MCPCentral.com

This article is the first in a two-part series discussing the use of XML as a storage mechanism for maintaining the state of a web client. The first installment deals with the advantages of using XML to maintain state, and begins the process by designing and building a VB object to be used for this purpose. The second part deals with using the object created in part 1 from within ASP and compares the performance of this methodology with that of the Microsoft state mechanism.

To do business on the Internet, a method of maintaining the state of the client is imperative. Whether state is used to maintain login status, a shopping cart, or personalized settings, keeping track of user variables from request to request on the web is a must. In addition to the state requirements of eCommerce, scaleability and speed are also necessities for high-volume sites. A site that has a whiz-bang shopping cart, but can’t handle high loads, or takes 30 seconds to serve a single page, will not be successful in the competitive world of eBusiness. Active Server Pages provides the capability to maintain state using the Session object, and on its own is also a very scaleable and fast solution. Unfortunately, using the Session object within ASP to maintain state can significantly impact the speed and scaleability of the application. For reasons involving the use of threads that are outside the scope of this article, sites that deal with high-volumes of traffic (more than 50 concurrent connections) may find that the Microsoft state mechanism in its current incarnation is not a viable solution.

Fortunately, we now have the ability to use XML to maintain client state for high-volume sites. To do so, we will create an Active-X object in Visual Basic that will serve as a replacement for the ASP-native Session object. We are able to avoid the threading issues faced by the Session object by saving our XML data to the hard-drive of the web server, which can be done quite simply by using the XML capabilities of ADO 2.5. This methodology also provides the added benefits of being persistent (it will not go away until you tell it to) and easily extensible. As well, since XML is a growing standard, future log-analyzers and other programs could use the files created to do statistical analysis and create reports about the visitors to your site.

To begin creating the object that will replace the Session object, we will need two public collections, a Data collection and a Keys collection. The Data collection will be used to access the values stored in the object, and the Keys collection will provide a programmatic method of determining what data is held therein. We will also need a number of public methods for this object, which are described below:

Start: The Start method is used to create a new user session. When a new user comes to the website, we will instantiate the object and call this method. It will return a GUID (Global Unique IDentifier) that will be used to identify the user for the duration of the session and to store the data on disk. This method also sets up the default values for a new session, including LastAccess, SessionStart and GUID. You could easily add your own default values here.

Save: The Save method is used at the end of each web page to store the values to disk. This method loads the data into an ADO 2.5 recordset and uses the save method to persist the recordset to disk in XML format. These XML files can be opened in the Internet Explorer browser if you are curious of their contents.

Load: The Load method retrieves an existing dataset from disk in XML format, storing it temporarily into an ADO recordset object. This recordset is traversed to return the data to the object’s public collections.

UpdateData: The UpdateData method is used to add a data item to the collection or change the value of an existing piece of data.

In addition to these public items, several private methods and functions are necessary to complete the functionality of this object. The API functions GetTempPath and CoCreateGuid are used in conjunction with the local functions in the modUtilities module called LocateTempPath and GetGUID. These functions determine the system temporary folder and create the Global Unique Identifiers. Finally, the modConstants module is used to store standard error messages for the object. Errors for this object fall in the 20000 range and plenty of room is left for you to add your own errors.

Please download and review the VB code for this object. To install onto your webserver, compile the code in VB6 to an Active-X dll. If the compilation is done on the web server, nothing more needs to be done at this point. If the object is moved from the system where it is compiled, to the webserver, you will need to use the regsvr32.exe utility to register the object.

In the second part of this article, we will put the object to the test by creating a set of sample ASP pages that use it, and create the same pages that use the Session object for comparison.