Session State Management

By: Joydip Kanjilal Date: November 3, 2007

ASP.NET, like traditional ASP, provides the facility to track a user's session using Session State. Web applications are built on Hypertext Transfer Protocol (HTTP).  HTTP being a stateless protocol, each request to the server from the client is understood as an independent request. ASP.NET provides a powerful way to store a user’s session specific data using the Session State which is accessible as long as the user’s session is alive.  This article discusses Session State, its advantages and disadvantages, the Session storage modes and how we can configure the same using the application’s web.config file.

Session, Session ID and Session State

A Session is defined as a session or the duration of connectivity between a client and a server application.  A Session object is created and maintained on the web server and is unique to a user’s session of communication with the web server.  Note that an object must be serializable in order to be persisted in the Session object.

When a Session starts, the browser sends a cookie with a session identifier along with every request.  The IIS web server uses this Session ID to determine whether it belongs to an existing session.  If none is found, a Session ID (120 - bit string) is generated along with the request.  The Session ID persists as long as the browser session is alive even though the session state expires after the specified timeout.  Hence, the same session ID can represent multiple sessions over time where the browser instance is the same.

Session State is a collection of objects that are stored in the memory of the web server.  But where is the Session State stored?  In II5, Session State is stored in the memory of the process aspnet_wp.exe.  In IIS6, by default all applications share the same application pool, i.e. the session state is stored in the memory of the process w3wp.exe.  They are not isolated per application basis, but instead per application pool (w3wp.exe).

Advantages and disadvantages of Session State

The advantages of using session state are as follows:

• Process independence
• Ease of implementation
• Durability
• Scalability

The disadvantages of using session state are:

• Low Performance for large volumes of data
• >Overhead involved for serializing and de-serializing the Session data

Storing Session State in ASP.NET

Session state in ASP.NET can be stored in one of the following three ways.

• InProc
• State Server
• SQL Server

Session state can be configured using the <sessionState> section in the application's web.config file.  Hence, we can increase the default Session timeout value to our desired value using the following statement in the web.config file.

Listing 1

<sessionState
  timeout="40"
/>

The above statement doubles the Session Timeout value from 20 minutes to 40 minutes.  Note that the Session Timeout value is a Sliding expiration one.

The following is the complete syntax for specifying Session State in the web.config file using the mode attribute.

Listing 2

<sessionState mode = <"inproc" | "sqlserver" | "stateserver">
        cookieless = <"true" | "false"> 
timeout = <positive integer indicating the session timeout in minutes>
   sqlconnectionstring = <SQL connection string that is only used in the SQLServer mode>
        server = <The server name that is only required when the mode is State Server>
        port = <The port number that is only required when the mode is State Server>

The following section discusses each of the settings shown in Listing 1 earlier, in detail.

Mode: This setting supports three options.  They are inproc, sqlserver, and stateserver.  As stated earlier, ASP.NET supports two modes: in process and out of process.   There are also two options for out-of-process state management: memory based (stateserver) and SQL Server based (sqlserver).

Cookieless: This setting takes a boolean value of either true or false to indicate whether the Session is a cookieless one.

Timeout: This indicates the Session timeout vale in minutes.  This is the duration for which a user's session is active.  Note that the session timeout is a sliding value; on each request the timeout period is set to the current time plus the timeout value.

SqlConnectionString: This identifies the database connection string that names the database used for mode sqlserver.

Server: In the out-of-process mode stateserver, it names the server that is running the required Windows NT service: ASPState.

Port: This identifies the port number that corresponds to the server setting for mode State Server.  Note that a port is an unsigned integer that uniquely identifies a process running over a network.

Storing Session State in the InProc Mode

The InProc mode of Session State storage is the fastest among all of the storage modes available and stores the Session data in the ASP.NET worker process.  In this case, if the amount of data that is stored in the Session is large, performance would be drastically affected.  In the InProc mode of Session state storage, the session state is stored in the memory space of an application domain and is volatile.  In this case, the session state will be lost if the ASP.NET worker process named aspnet_wp.exe recycles or if the application domain restarts.  The Session State here entirely depends on the lifetime of the application domain that it runs on.  Note that the Session_End event which is fired internally by the web server is supported only in InProc mode. Note that even if the Session State is set to read only using the EnableSessionState attribute, in the InProc mode one can still modify the session.  The Session_OnEnd event is invoked by the runtime environment when we make a call to the Session.Abandon() method or when the user's session times out.  Further, any change made in the settings in the web.config file unloads the application domain and the Session State too.

Storing Session State in a State Server

The StateServer mode uses a stand-alone Microsoft Windows service that is independent of IIS and can run on a separate server.  In the State Server mode of Session State storage, the session state is serialized and stored in memory in a separate process that is managed by the aspnet_state.exe file.  Note that State Server can be on a different system.  This storage mode has some performance drawbacks due to the overhead involved in serialization and de-serialization of objects.  Note that the ASP.NET State Service is like any other NT/2000 service and runs as its own process and has its own memory space.

The following is the required setting in the web.config file to store the Session State in the State Server mode.

<sessionState mode="StateServer"
 stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=joydip;password=joydip"
 cookieless="false" timeout="20"/>

The primary advantage of storing the Session State in a State Server is that it is not in the same process as the ASP.NET and a crash of ASP.NET would in no way destroy the session data. Secondly, this mode of Session State storage enables to share the information across a web garden or a web farm.

The main disadvantage, however, is that this mode is slow compared to the InProc mode as it is stored in an external process.

Storing Session State using SQL Server

The SQL Server mode of Session State storage offers a reliable, secure and centralized storage of a session state with transactional facilities.  In this storage mode, the Session data is serialized and stored in a database table in the SQL Server database.  It can typically be used in the web farms.  In the SQL Server mode of Session State storage, the session state is serialized and stored in the SQL Server.  It has performance bottlenecks as in the State Server mode of Session State storage due to the overhead involved in serialization and de-serialization of the objects that are stored and retrieved to and from the Session.  SQL Server is more secure than the InProc or the State server modes of Session State storages as the data can be secured easily by configuring the SQL Server security.

The InstallSqlState.sql file has to be located in the system and executed.  This would create the necessary database and tables in the tempdb database to store the Session data.  To remove all the databases and the tables created earlier using the InstallSqlState.sql file, the UninstallSQLState.sql file can be used.  The web.config file has to be modified accordingly.  The following is the required setting in the web.config file to store the Session State in the SQL Server mode.

<sessionState mode="SQLServer"
  sqlConnectionString="data source=server;user id=joydip;password=joydip"
  cookieless="false" timeout="20" />

Okay, but which one should I choose?

So, which one to choose?  Which Session state storage mode is the best?  We have to choose between speed, reliability, security and scalability.

For sites that run in a single server, the InProc storage mode in the best.  It is the fastest of all the three modes, but it has its own limitations.  The major problem is that it is volatile.  In the InProc mode of storage, the durability of the data that is stored in the Session State is dependent on the life time Application Domain that the application runs in.  Once the Application Domain restarts or shuts down, the Session is lost.  In a production environment, the InProc mode of Session State storage is not feasible.  When we have to go for WebFarms, the OutProc mode is the best; especially when the traffic is heavy on the site.   The SQLServer mode of storage is suited when we need to secure the Session data or when we require scalability and reliability, but it takes more time to store and retrieve data to and from the database table.  We have to decide the right type of Session state storage mode based on the context by choosing between speed, scalability, and reliability.

Sharing Session State between Classic ASP and ASP.NET

ASP and ASP.NET sessions are not easily shareable.  Sharing session state between Classic ASP and ASP.NET can be possible through one of the following ways:

• Storing the data in a common database or in the cookies
• Passing the data from one page to another page using query strings
• Using a 3rd party component for sharing session data

Storing, retrieving and deleting objects in the Session

In order to add objects from the Session use the following method:

HttpSessionState.Session.Add(name,value);

This adds an object to the Session state, the name and the value of the item to be added being passed to this method as parameters.  Further, the HttpSessionState class is present in the System.Web namespace in the System.Web.dll file.

Alternatively, we can add objects to the Session.

HttpSessionState.Session["UserName"] = "Joydip";

This automatically creates a new item called "UserName" in the Session State Collection (if none exists) and sets its value to "Joydip."

The following method is used to retrieve a previously stored object from the Session state.

string userName = HttpSessionState.Session["UserName"].ToString();

Note that the ToString() method is called because data is stored in the Session state as objects. Therefore, the conversion or casting to the appropriate type is necessary in the above example to retrieve the current User’s name as a string.

The following method is used to remove an object from the Session state.

HttpSessionState.Remove(objectName);

This method deletes the object specified as parameter from the Session State Collection, provided the same exists.  In this case, if the session-state collection does not contain the element specified, the collection remains unchanged, but no exception is thrown.

To clear the Session use either of the following:

Session.Abandon();

or

Session.Clear();

The difference between the Session.Abandon() and the Session.Clear() method is that if you call Session.Abandon(), Session_End will be fired (for InProc mode) and in the next request, Session_Start will be fired.  Session.Clear( ) just clears the session data without killing it.

Enabling and disabling Session State in ASP.NET

Session State in ASP.NET can be enabled and disabled both at the page and application levels. This section discusses how we can enable and disable Session state at both the page and application levels.

Page Level

We can disable Session State for the pages that do not require access to Session data using the EnableSessionState statement in the Page directive of a page as shown below.

<%@ Page EnableSessionState="False" %>

Session State for a page can also be set to read only for pages that require access to the Session data, but do not modify them.  Refer to the statement below.

<%@ Page EnableSessionState="ReadOnly" %>

Application Level

Session State can also be disabled for all the pages of the application by specifying the same at the application level in the configurations section of the web.config file.

<configuration>
  <system.web>
    <pages enableSessionState="false" />
  </system.web>
</configuration>

It is also possible to set the Session State to read-only for all the pages in the application.

<configuration>
  <system.web>
    <pages enableSessionState="ReadOnly" />
  </system.web>
</configuration>

Points to remember

This section discusses some important points that one should keep in mind when working with Session State in ASP.NET.  I have put together some of the most important points here.

1. Response.Redirect("~/menu.aspx", false)
2. We should be well aware of the amount of the data that we store in the Session, particularly for sites that have a heavy traffic.  In a distributed web server environment, the use of Session variables can degrade performance.
3. The Session IDs are stored in the Cookies in the Client side and are used for communication between the Server and the Client.  If the Session does not contain a Cookie, the Session ID is maintained using the URL only.
4. It should be noted that the SessionID lasts as long as the user’s session of communication with the web server is active, i.e., as long as the browser instance is unchanged.  This can happen even after expiry of the Session after the specified timeout period.  Note that if the application has never stored anything in the session state, a new session state with a new Session ID is created with every request.  In SQLServer mode of Session State storage, the session expiration is carried out by the SQL Agent using a registered job.
5. The Session timeout value is specified web.config file.  It is a sliding expiration value and indicates the time (in minutes) that the Session can be idle before it is abandoned.  When a session times out, the session data is flushed out, the Session object is killed and a new one is created on a subsequent hit to the page.  The Session timeout value is a sliding expiration value.
6. Note that the Session state is available only after the HttpApplication.AcquireRequestState event is called.  The Session_End event is supported only in the InProc mode and is fired internally by the Web Server, based on an internal timer.  Thus, there is no HttpRequest that is associated when that happens.  This is why the methods Response.Redirect or Server.Transfer do not work in the Session_End event.  The Session_OnEnd event is called when we make a call to the Session.Abandon method or when the Session times out.
7. Storing the basic types in the Session state is much faster compared to storing object types due to the serialization and de-serialization overhead involved.
8. The IsNewSession property of the HttpSessionState class can be used to detect whether a Session has timed out or was abandoned.
9. Remember never to use a Response.Redirect or Server.Transfer method call after you set the Session in the login page of your application.  Both these methods call the Response.End method internally.  The Session ID would be lost as the Response.End method stops execution of the page.  Use the FormsAuthentication.RedirectFromLoginPage method instead. Alternatively, you can use the following overloaded version of the Response.Redirect method.
10. This would not abort the current thread and would prevent the Session ID from being lost.

Suggested Readings

State Management in ASP.NET
ASP.NET Session Management Internals
State Management in ASP.NET
ASP.NET offers new state management techniques
Session State -- MSDN
Session State Overview -- MSDN
Custom session state management in ASP.NET 1.1

Conclusion

Session State is an often misunderstood concept to the ASP.NET professionals.  Often we make mistakes in selecting when to use the Session or store data in the Session.  The proper selection of Session State Storage mechanism is also absolutely essential for a web application.  ASP.NET provides three session state storage modes: In-Proc, State Server, and SQL Server.  This article has discussed all three Session State storage modes in detail with code examples whenever necessary.  It has also discussed the pros and cons of using the Session State to store user data. It should be noted that we should choose the right type of the Session Storage mode for our application and at the same time ensure that we store the right type of the objects in the Session. Storing too many objects in the Session would degrade the performance of the application to a great extent.  I welcome readers' comments and suggestions.