One of the core aspects that software developers must always deal with when building applications is handling state information. This task is made more difficult in Web applications because HTTP is by its very nature a stateless protocol that doesn’t remember anything about a user between requests.

However, ASP.NET developers have a plethora of tools available that allow them to effectively and efficiently store and retrieve state information at a variety of levels. Let’s examine the mechanisms that ASP.NET provides to enable developers to deal with state management.

The problem with user sessions in ASP
The stateless nature of HTTP makes the inclusion of a mechanism to save application state between user requests a must—the server must be able to identify the same user across multiple requests. Classic ASP included a Session object that accomplished this, but unfortunately, that implementation has two main weaknesses. First, the 120-bit session ID used to identify the session is always stored as a cookie on the browser. So if the security policy of a user’s employer disallows cookies, the Session object cannot be populated.

Second, the data associated with the session and accessed through the session ID is stored on the Web server that processed the initial request and started the session. As a result, the session data can’t be shared in a Web farm scenario where multiple Web servers are processing requests from multiple clients. Although programmatic techniques and system software, such as the Windows 2000 clustering services and Application Center 2000, can be configured to force a client to access the same Web server for each request (referred to as “sticky IP”), the overhead and possible imbalance that this situation creates reduces scalability.

ASP.NET’s improved model offers more alternatives
The ASP.NET session implementation addresses both of these weaknesses by allowing for “cookieless” sessions and off-server storage of session data. The ASP.NET session state module is configured declaratively in the Web.config file like so:
<sessionState mode=”InProc” cookieless=”false” timeout=”20″ />

In this case, the mode attribute is set to InProc (the default) to indicate that the session state is stored in memory by ASP.NET and that cookies will not be used to pass the session ID. Instead, the session ID is inserted into the query string for a page’s URL. For example, using InProc mode, after a session is established, a call to a hypothetical ASP.NET page would look something like the following:

The long alphanumeric string in parentheses is the session ID. The ASP.NET engine extracts the session ID from the query string and can then associate the user request with the appropriate session. In this way, cookies are not required, nor are hidden form fields. So pages without forms can still participate in the session.

Use only as directed

As with ASP before it, session state management in ASP.NET requires overhead. So if a particular page will not be accessing the Session object, developers can set the EnableSessionState attribute of the Page directive for that page to False. Session state can be disabled for an entire site by setting the mode attribute of the sessionState element to Off in the Web.config file.

Session management with SQL Server
ASP.NET also allows you to store session data on a database server by changing the mode attribute to SqlServer. In this case, ASP.NET attempts to store session data on the SQL Server specified by a sqlConnectionString attribute that would contain the data source and security credentials necessary to log on to the server.

To configure the SQL Server with the appropriate database objects, an administrator would also need to create the ASPState database by running the InstallState.sql script found in the WinDir\Microsoft.Net\Framework\Version folder (where WinDir is the name of your server’s Windows folder and Version is the installation folder for the appropriate version of the .NET Framework you’re using).

Once the SQL Server is configured, the application code should run identically to the InProc mode. But keep in mind that since the data is not stored in local memory, objects stored in Session state will need to be serialized and deserialized for transport across the network to and from the database server, which will affect performance. By storing Session state in the database, you’re effectively trading performance for scalability and reliability.

StateServer session management
A third option, accomplished by setting the mode attribute to StateServer, is storing session data in a separate in-memory cache controlled by a Windows service running on a separate machine. The state service, called the ASP.NET State Service (aspnet_state.exe), is configured by the stateConnectionString attribute in the Web.config file. It specifies the service’s server and the port it monitors:
<sessionState mode=”StateServer” stateConnectionString=”tcpip=myserver:42424″
    cookieless=”false” timeout=”20″ />


In this case, the state service is running on a machine called myserver on port 42424, which is the default. At the server, the port can be changed by editing the Port value in the HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state registry key.

Obviously, using the state service has the advantages of process isolation and sharability across a Web farm. However, if the state service is stopped, all session data is lost. In other words, the state service does not persistently store the data as SQL Server does; it simply holds it in memory.