session manegment in ASP.NET

Hypertext Transfer Protocol (HTTP) is stateless: a client computer running a web browser must establish a new Transmission Control Protocol (TCP) network connection to the web server with each new HTTP GET or POST request. The web server, therefore, cannot rely on an established TCP network connection for longer than a single HTTP GET or POST operation. Session management is the technique used by the web developer to make the stateless HTTP protocol support session state. For example, once a user has authenticated oneself to the web server, his/her next HTTP request (GET or POST) should not cause the web server to ask him/her for him/her account and password again.

The session information is stored on the web server using the session identifier (session ID) generated as a result of the first (sometimes the first authenticated) request from the end user running a web browser. The "storage" of session IDs and the associated session data (user name, account number, etc.) on the web server is accomplished using a variety of techniques including, but not limited to: local memory, flat files, and databases.

In situations where multiple web servers must share knowledge of session state (as is typical in a cluster environment) session information must be shared between the cluster nodes that are running web server software. Methods for sharing session state between nodes in a cluster include: multicasting session information to member nodes (JGroups for one example of this technique), sharing session information with a partner node using distributed shared memory or memory virtualization, sharing session information between nodes using network sockets, storing session information on a shared file system such as the network file system or the global file system, or storing the session information outside the cluster in a database.

HTTP, the underlying transport of the Web, is a memory-less protocol. Every time a client requests an application, HTTP has no idea of the caller's identity—it simply forwards the request to the Web server. To allow for a level of continuity in a Web-based application, you must use the technologies discussed in this article, which allow both JSP and Microsoft® ASP.NET applications to retain state in between client requests.

Both JSP and ASP.NET use the concept of sessions and Session objects to store data unique to a particular client while that client is connected to a Web application. For example, when a user logs on to a Web application, her login name, password, and other pertinent information might be stored in a Session variable and maintained during her visit to the site so that it can be accessed when needed. When a session begins, the requesting browser is given unique piece of information, or "ticket," that is presented by the browser on subsequent visits to identify the user. The Web application can then, for example, customize the settings for that user when she visits, since it can find her personal preferences using the information stored in the Session object referenced by the ticket.

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.

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:

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