ASP.NET Session State Modes Explained

ASP.NET Session State is significantly improved when compared to sessions in classic ASP. In ASP 3.0, using of sessions is almost considered as bad programming habit. ASP.NET Session State solves most of the old problems with scalability, reliability, using of sessions on web farms or web gardens etc. Depending on where session data are stored, ASP.NET session state supports five different modes.

They are all listed in SessionStateMode enumeration:

Off - Used to disable sessions on website.
InProc - Sessions are stored inside of application's process on web server. Depending of IIS version used that could be aspnet_wp.exe or w3wp.exe.
StateServer - Sessions are stored using State Server windows service.
SQLServer - SQL Server database is used to store sessions' data
Custom - Manage session state using custom session state provider. Storage could be anything you implement in provider.

To specify session state mode in web.config, select one of these values for sessionState mode parameter:

<sessionState mode="Off|InProc|StateServer|SQLServer|Custom" />

In web.config file, <sessionState > element is located under <configuration>, <system.web> element.

Session State mode: Off

Off mode is used to disable sessions on complete website. Use Off mode if your web application doesn't use sessions.

Disabling of Session State will increase performances of ASP.NET application. It is not enough to just not use session state variables. Every time visitor make request to website, ASP.NET will create new session for that user. This takes some processing time and uses server's memory. Also, Session_Start procedure is executed. With Session State disabled, application executes faster and requires less memory.

To disable Session State in complete ASP.NET application, use this markup code in web.config:

<sessionState mode="Off" />

If you need sessions on part of application, but not on all pages, you can disable session state on page level. Use EnableSessionState parameter of Page directive to disable sessions for certain page. Code could look like this:

<%@ Page EnableSessionState="False" %>

Or, to make session state read only, use ReadOnly value, like this:

<%@ Page EnableSessionState="ReadOnly" %>

Default value of EnableSessionState parameter is True. If you need to disable sessions or make it read on most, but not all pages, you can change default behavior in web.config. For example this markup code will change default value for pages to ReadOnly:

<configuration>
     <system.web>
       <!--By default, pages will have read only access to session state-->
       <pages enableSessionState="ReadOnly" />
     </system.web>
</configuration>

Session State mode: InProc

InProc is default value. When InProc is used, session data is stored in web server's memory inside of application process. Because of that, InProc is fastest of all modes.

But, if ASP.NET process restarts or is recycled, all session variables are deleted. This could be serious problem because restart of ASP.NET application could occur very often due to numerous reasons (see Restart and Stop of ASP.NET Application ).

Since session variables are stored inside of process, they can't be used on websites which uses multiple processes. If website is hosted on multiple servers (web farm) or multiple processors (web garden), every processor will run its own process. So, if InProc is used, session data can't be shared between servers, although there is an option to use load balancing to direct all requests from certain IP address to same server.

One more problem with InProc is scalability. Session data are stored in server's memory. If there are a lot of concurrent visitors, web server could easily run out of physical memory. When this happens, Windows will start paging on disc which slows down application and decreases performances.

More about how to use default InProc mode, read in InProc Mode in ASP.NET Session State tutorial.

Session State mode: StateServer

StateServer mode solves all problems mentioned if InProc mode is used. In StateServer mode, sessions are stored using State Server windows service, in aspnet_state.exe process.

Since session data are stored using Windows service and outside of ASP.NET application process, session variables are intact when ASP.NET application restarts. But, they will be deleted if State Server restart.

State Server could be located on same machine as web server, or on separated computer. If dedicated State Server is used, web server's memory remains free which is more scalable solution.

At last, State Server supports multiple processes. It could be used on web farms or web gardens.

More about how to use State Server as storage for session data and how to implement it in various scenarios, you can read in How to Store Session Data in ASP.NET State Server tutorial.

Session State mode: SQLServer

SQLServer mode uses SQL Server database to store session data. Like State Server, SQL Server also stores variables outside of ASP.NET process. This is most reliable of all possible modes. Sessions stored in SQL Server database could survive web server restart, and also SQL Server restart. As drawback, SQLServer is slowest mode. This loss in speed is often ignored if reliability is first priority, i.e. when session data are very important.

More about using SQL Server as session state storage you can find in How to store ASP.NET session state on SQL Server tutorial.

Session State mode: Custom

On this way, you get full control over session state management and session could be stored in different places. This option is often used to store sessions in databases like MySQL, MS Access, Oracle etc. But, theoretically custom provider could work with anything, like text file, XML file, call web service etc. There is nice example on MSDN which shows how to implement custom session provider for MS Access database. You can use it as a template and according to your needs, change it to work with some other data source.

Decide where to store your sessions

On small traffic website, any option will work well. Since InProc method is default and already configured to use,  you'll probably be happy with InProc mode.

Notice that, when InProc is used and application restart occurs, all sessions are lost. Application restart could occur for many reasons, but generally, if you work a lot on your website, like change frequently web.config, Global.asax, .aspx pages, assemblies in /bin folder etc., application will restart frequently. In this case, it is probably better to switch to some out of process mode.

In the other hand, if your website is built using some completed application, like BlogEngine.Net, YetAnotherForum, DotNetNuke etc., and you just use its features without often changes in application code, InProc will work fine.

On high traffic websites with thousands of users online, sessions will quickly take all memory if InProc mode is used. For high traffic websites, InProc is probably not scalable option, but that also depends of how much data you stored in sessions, did you increased session timeout etc.

If website is hosted on multiple servers (web farm) or multiple processors (web garden), it requires State Server or SQL Server option, because InProc mode can't share sessions between servers or processors.

State Server and SQL Server modes require serialization of objects before storing them to session variable. If InProc is used, you can store any .Net type in memory. But, if State Server or SQL Server is used, you can store only primitive types or serializable classes.

State Server and SQL Server are very similar. Between State Server and SQL Server, I personally prefer SQL Server. SQL Server is scalable solution and more reliable than State Server and InProc, especially if Sql cluster is used to remove "single point of failure". Some developers observe that SQL Server is a little slower than State Server because SQL Server must read and write to disc, and State Server reads from memory which is faster. But, SQL Server has very efficient caching mechanism. Frequently used data stays in cache to get faster access. On this way, difference in performances between State Server and SQL Server although still exist, becomes too small to be decisive factor.

Shared web hosting providers usually don't allow using of State Server. If your website is stored on shared hosting, only dilemma is between InProc and SQL Server.

Remarks

You may disable sessions from two main reasons: either your application is stateless, or you use some other way to track user's data. More about different options that could be used instead of session state you can read in ASP.NET Session State Alternatives tutorial.

Time consuming operation could be serialization/deserialization if you store a lot of objects in sessions. InProc mode allows any type to be stored without serialization, but State Server and SQL Server requires serialiazation of object before it could be stored.

Serialization/deserialization is relatively slow process which could decrease performances. If testing shows that this is a problem, you can try to replace some objects with several primitive types which don't require serialization. The fastest option is to use only primitive types (int, string, Byte, DateTime, IntPtr etc.) in session variables. You will end up with far more variables, but they will work faster.

Happy coding!

Tutorial toolbar:  Tell A Friend  |  Add to favorites  |  Feedback  |   Google