To date, we've talked about the infrastructure of Active Server Pages (ASP) and its potential with respect to developing large-scale, enterprise applications. So far, we've seen the capabilities of the Request and Response objects and briefly talked about other objects intrinsic to the ASP runtime environment. Coverage of this material was undoubtedly lengthy; however, I felt compelled to give you a thorough introduction to the topic preparing you for some of the more powerful features of ASP we would cover in articles to come.

In this article, I’ll explore strategies for managing transient application state using ASP. Often referred to as simply ‘state management’, the concept of maintaining data for a specific user or application over a series of HTTP requests often poses some interesting problems related to web application development.

I’ll introduce a new object in the ASP object model: the Session object. You’ll use the Session object to manage information for individual users of a particular application. In a later installment, we’ll use another object, the Application object to store common information that can be shared between all users of a single ASP application.

Applications can be ‘stateless’ or ‘stateful’. HTTP is a ‘stateless’ protocol. We’ll talk more about ‘stateful’ later, but let it suffice to say that HTTP does not attempt to retain information, or state, about the current connection after a request completes. In a previous article, I introduced you to some of the characteristics of HTTP especially the request/response nature of interactions between clients (browsers) and servers.

In that article, we learned that when a browser needs to obtain a resource, it sends the server an HTTP Request message containing various pieces of information telling the server the nature of the request and, most importantly, the resource or document that it needs. When the server receives and processes this request, it generates an HTTP Response message containing, in some form or fashion, the contents of the requested document.

We introduce complications into this scenario when information needs to survive or be recorded between several requests. It is not uncommon to encounter the same state management requirements in web applications as we do in conventional client-server applications – it’s just harder to implement at times because the rules are slightly different.

To implement consistent user sessions on the Web, ASP provides a flexible solution that requires no special programming. The Session object, one of the intrinsic objects supported by ASP, provides the developer with a means of storing and retrieving data as well as performing session-related functions.

Session("User")="Jules"

Value can be retrieved from the Session object by referencing the Session object by name, as in the following:

Welcome <% = Session("User") %>!

Or

<% Response.Write Session("PR").Name %>

The Session object maintains these name/value pairs for the lifetime of a user's logical session. For each ASP page requested by a user, the Session object preserves the information in the server’s memory.

The browser returns this cookie with each request made to the virtual web application directory /MyASPApp, giving ASP the opportunity to find the session-specific data previously stored.

Furthermore, in more complex applications, if you are attempting to use a clustering strategy that allows multiple requests to be serviced by a number of different servers, the concept of session state stored on a particular server tends to break down in a hurry.

There are times when the Session object may not be robust enough for your application needs. Although you may still choose to use the Session object for some non-critical pieces of data, your application may benefit from using an external storage mechanism such as relational database server to store state information.

When you think of it, a database server provides a very suitable model for storing an application’s state. For one, the database can reside anywhere on the network and be accessible from any number of servers. Also, database servers today offer, at least, some performance enhancement features, referential integrity and even redundancy. For the most part, utilizing this storage medium to store transient application state is no more complex than any other database application.

This strategy tends to weaken when you think of the numerous IP addresses dynamically assigned by Internet Service Providers that probably expire in a couple of hours. Better yet, if the client is connecting via a proxy server, they could be one of a hundred clients masquerading behind the proxy’s single IP address.

Once identifying the session is no longer a problem, you need to implement the code to persist the session state. You may choose one of several methods:

Given a Session ID and the desired property name, you could either insert a new value or retrieve an existing value from the table. As long as property names are kept unique and  data storage needs are limited to simple data types, you have essentially created a custom version of the ASP Session object.

What Happens When It's All Over?

If you choose to store state information in an external table, one final complication may be garbage collection. In other words, when a session ‘ends’ what do you do with information previously recorded in the database?

A straightforward way to approach this in the self-managed session model, is to create your own methods of construction and destruction with respect to the individual session.

For example, when you create a session for a user, your application is responsible for the destruction of that session via your custom Session object. This strategy obviously has a couple of holes in that users have a nasty habit of not always logging off.

One last approach might be the simplest, but could also be the least reusable. You could encapsulate the state in the HTTP Request and Response messages.

Although this technique is certainly not new, and is not limited to ASP applications, HTML provides for encapsulating state information through the use of both normal, visible form fields and form fields having the HIDDEN attribute.

The basic concept is that given a known amount of state, you can store name/value pairs in form fields, basically eliminating the need for server-based application state.

Using this technique gives you the ability to use the standard HTML form submission model to create and encapsulate the HTTP Request and the ASP Response object to query property specific information. To complete the model, you have to carry the state received from the HTTP Request forward to the HTTP Response by regenerating the additional hidden fields and their respective values.

An example HTML form using this technique might initially look as follows.

When returning information to the client, our server side script generates the next data entry form preserving state from previous forms in hidden fields as follows:

The HTTP request/response interaction model has been instrumental in creating one of the most effective distributed processing platforms of all time: the World Wide Web. HTTP has its limitations and certainly its’ ‘stateless’ nature forces us as software developers to sometimes think in a totally different paradigm spending most of our time dealing with the hassles of storing and retrieving data instead of pursuing the more interesting aspects of our application.

When all is said and done, you have a choice. In this article I’ve attempted to outline a couple of these choices for you at a reasonably high level and offer some potential architectural suggestions for those of you planning large-scale applications.

In summary, remember a couple of things...

For reasonably lightweight, single server applications (and product demos), the ASP Session object provides a simple solution for storing and retrieving transient application state information. If you keep in mind what you’re attempting to store in this object and don’t overuse it, you’ll get by just fine.

For more complex applications, especially those with significant state management requirements and those that must maintain state across multiple servers and multiple applications you may need to investigate some of the alternatives we’ve discussed or formulate your own state management strategy.