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:

• In Process (InProc)
• State Server
• SQL Server

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:

	Advantages	Disadvantages
In Process	Default. Fastest. Simplest.	Session information lost if the worker process (either aspnet_wp.exe or w3wp.exe) is restarted (for a developer this includes a rebuild on the development machine). Not suitable for web-farms.
State Server	Tolerant of worker process crashes. Suitable for web-farms.	Slower than In-Process. State is maintained on a single server, and thus a single point of failure (only an issue if site up-time and fault tolerance is an issue)
SQL Server	Tolerant of worker process crashes. Suitable for web-farms. Supports failover clusters.	Requires SQL Server. Slowest method. Most complex to set up.

In Process

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 is the default method - so its simple because no configuration is required on the part of the developer.
• Is is the fastest method.

It also has the following disadvantages:

• All session information is lost if the aspnet_wp.exe process is restarted. This also means that session information will be lost after a recompile of the application, but there are numerous other times when the aspnet_wp.exe process will be recycled.
• It is not suitable for use on a web-farm, i.e. where there is more than one computer that could respond to a request. This is simply because if a subsequent request is handled by a different server then that server will not have access to the session information (because the session information is stored on a different server).

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".

State Server

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:

• It is tolerant of the worker process being recycled. For developers this has the advantage (or disadvantage!) that session information is maintained across compiles of the application.
• It is suitable for use on web-farms.

and the following disadvantages:

• It is slightly slower and more resource demanding than the in-process model, because:
  1. there is an extra level of communication required between processes and
  2. everything in the session needs to be serialized and de-serialized on each web request.
• State information is stored on a single server - this is not an issue normally but might be if you need to avoid a single point of failure (in which case SQL Server is the route to go because it supports failover servers).

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 "stateConnectionString="tcpip=127.0.0.1:42424", this is reasonable if the state server is on the same server (The IP address 127.0.0.1 is by definition the local machine). If however you are running in a web-server environment then it is vitally important that you set the server name, so substitute the name of a server for "server1" in the above example. Otherwise each server will communicate with the state server process running locally and session information will not be shared between servers.

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.

SQL Server

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:

• Tolerant of worker process crashes.
• Suitable for web-farms.
• Can be configured to work in a failover cluster. Basically the session information is stored on more than one server so if a database fails then the session information is not lost. This is ideally suited to environments where high availability is required (but it doesn't come cheap!).

and the following disadvantages:

• It requires SQL Server
• It is the slower than both In-Proc and State-Server methods.
• Is the most complex to set up.

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.

References

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconASPStateManagement.asp

Good article on ASP.NET State Management.

http://msdn.microsoft.com/library/en-us/cpgenref/html/gngrfsessionstatesection.asp

Article on the various configuration parameters for session state in the web.config file.

---

These notes are believed to be correct for .NET 1.1 and .NET 2, and may apply to other versions as well.