Session management options in ASP.NET

Introduction

One of the core aspects that classic ASP developers (including me) 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.

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:

<sessionStatemode="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:

http://my.website.com/(55mfgh55vgblurtywsityvjq)/education.aspx

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.

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. If a particular page will be accessing the Session object and not altering the value of the session, then set the EnableSessionState attribute of the Page directive for that page to Readonly. Session state can be disabled for an entire site by setting the mode attribute of the sessionState element to Off in the Web.config.

ASP.NET offers three session management solutions. They are:

InProcess,

StateServer (outProcess),

SQLServer (database based)

I am going to explain in detail about the new session management options with ASP.NET, especially SQLSEVER and STATESERVER.

InProc

This is same as the conventional ASP session management. Session is stored in memory on the web server.

StateServer session management

A second 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:

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.

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.

Pros and cons of the three session management solutions in brief

InProc - stored in memory on web server

This is the default setting.

Pros: least overhead, fastest performance

Cons: breaks web clusters, restarting IIS loses sessions

StateServer - managed by a remote service (aspnet_state)

HTTP protocol over TCP port.

Pros: reasonably fast, works with clusters

Cons: clear text, no authentication, overflows...

SQLServer - stored in SQL Server DB tables

Uses normal ODBC connection.

Pros: reliable, scalable

Cons: relatively slow, much overhead

Points of Interest

When you are upgrading an ASP application to ASP.NET, some times you may have to deal with the situation where in we need to pass state information between an ASP page and ASP.NET form. One way of accomplishing this is using cookies. Since cookies are stored in client side, when the browser requests a page, the cookie information is automatically send as part of the browser request. Because of this a cookie can be created by an ASP application and read by ASP.NET application when the browser is redirected to that ASP.NET page.

History

Version 1.1.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

in my application - when I traverse for sometime to various tabs - suddenly login,aspx page is displayed.
When I checked logs - but no debugger statement printed there..and no javascript alerts are seen.

So I verified web.config for timeout properties but couldnot find anything to be changed

I have a query regarding redirection to Login page, which I am not being able to trace out.

When I click on any of the tab in my application (which internally loads a new aspx page) sometimes it
is redirected to Login.aspx, which is unexpected. Couldnot debug why this is happening even by javascript alerts and C# debugging statements.

Below is the view source piece from Login.aspx, just for clue
<form name="Form1" method="post" action="login.aspx?ReturnUrl=%2fValuations%2fToDoList.aspx" id="Form1">

Valuations is the dll of application and ToDoList.aspx is the tab page I clicked which should load, but suddenly Login.aspx page is displayed. I traced the complete solution project.

- in web.config
<authorization>
<deny users="?"/>

</authorization>

- -suddenly while traversing in the application it redirects to login.aspx including return url as stated earlier and also if we keep the application idle for 5-10 mins and clicks somewhere, still redirects....

Hi,
Can you please let me how do you prevent session sharing in multi-tabbed browsers?
The user can type the application URL in another tab and you get multiple instances of the application sharing the same session.
It also happens when the user does a File --> New Window.
How would you differentiate between multiple instances of the web applicatin and a refresh?
Thanks

This is a nice article you've posted, it helped me get some introduction for using SQL Server for Session Management. I'm about to make a test application for that and I just noticed that there was no file with the name "InstallState.sql" you mentioned. But there is a file called InstallSqlState.sql so I thought I should atleast notify you so that you can make a correction on this if its necessary offcourse.