Pros and Cons of using ASP.NET Session State Server (instead of InProc)?

Question

Before I start using Session State server for the benefit of making session state more robust in my apps compared to InProc state, I'd like to find a list of Pros and Cons for evaluation.

Update 1: Also about surviving application pool recycles?

Update 2: What about longevity of sessions and their endings?

Answer 1

Here's the canonical analysis of the pros and cons of your three options, from Rob Howard's ASP.NET Session State article:

• In process. In process will perform best because the session state memory is kept within the ASP.NET process. For Web applications hosted on a single server, applications in which the user is guaranteed to be re-directed to the correct server, or when session state data is not critical (in the sense that it can be re-constructed or re-populated), this is the mode to choose.

• Out of process. This mode is best used when performance is important but you can't guarantee which server a user will request an application from. With out-of-process mode, you get the performance of reading from memory and the reliability of a separate process that manages the state for all servers.

• SQL Server. This mode is best used when the reliability of the data is fundamental to the stability of the application, as the database can be clustered for failure scenarios. The performance isn't as fast as out of process, but the tradeoff is the higher level of reliability.

The out-of-process (aka "StateServer") and SQL-Server options both survive web application restarts (including application pool cycling) and both make session data available to multiple servers in a cluster / farm.

Finally, it may go without saying, but the basic in-process setup is the easiest to configure, which is a meaningful "pro" in many environments.

Tim Sneath's ASP.NET Session State: Architectural and Performance Considerations adds some additional information, and the MSDN topic on Session State Modes is a reliable, up-to-date source.