Cry about... .NET How To ...
How to decide which method to use to store session information
HTML (which is what gets displayed in your browser) is great for displaying web pages, but is a stateless protocol. So each page is dealt with as an isolated (request and response) transaction and there is no management of which browser a request came from.
ASP.NET has the concept of a "session", which starts when a client first requests a page and ends after a definable period of inactivity. ASP.NET sends a unique cookie to the browser with each page which the browser then sends back for each subsequent page request which enables the server to associate each request with a session.
As well as the information ASP.NET stores in the session, applications can also store information in the session through the session object.
ASP.NET provides three methods to store session information:
InProc is the default method, but which is best for your application? The following is provided as a summary of the strengths and weaknesses of each:
Storing session information "In Process" (also sometimes referred to as "InProc") means that all session information is stored in the worker process "aspnet_wp.exe". It has the following advantages:
It also has the following disadvantages:
The following is the entry in the web.config file to configure session information to be stored InProc:
<sessionState mode="InProc" cookieless="false" timeout="20" />
The default configuration installed will also contain entries for "stateConnectionString" and "sqlConnectionString". These are default entries that are only used if the "mode" is changed and can be ignored if storing "InProc".
With the "State Server" model session information is stored in a separate "state server" process. The worker process (aspnet_wp.exe) will communicate with the State Server (aspnet_state.exe) to store and retrieve session information.
If you are working in an environment where there is more than one web server then another key difference from the in-process model is that all the servers should be configured to talk to the same state server process. This is a configuration issue and it would be easy to (wrongly) configure a web farm to use separate state server process on each server.
Storing session information in the state server has the following advantages:
and the following disadvantages:
To configure to use the state server model requires the sessionState parameter in the web.config file to be updated:
<sessionState mode="StateServer" stateConnectionString="tcpip=server1:42424" cookieless="false" timeout="20" />
The default entry for stateConnectionString is "
You also need to ensure that the state server is running on the chosen server. Do this by looking at the services on the server and ensure that "ASP.NET State Service" is started and set to "Automatic" start-up.
In "SQL Server" mode session information is stored in an SQL Server database. The worker process (aspnet_wp.exe) will communicate with the SQL Server database to store and retrieve session information.
SQL Mode has the following advantages:
and the following disadvantages:
I have yet to use SQL Server for storing state information. For an article on how to store session state information in SQL Server see http://www.dotnetbips.com/displayarticle.aspx?id=14. Please note that this is an offsite link.
These notes are believed to be correct for .NET 1.1 and .NET 2, and may apply to other versions as well.
About the author: Brian Cryer is a dedicated software developer and webmaster. For his day job he develops websites and desktop applications as well as providing IT services. He moonlights as a technical author and consultant.