Before I start using Session State server for the benefit of making session state more robust in may apps compared to InProc state, I'd like to find a list of Pros and Cons for evaluation.
Update 1: Also what about surviving application pool recycles?
Update 2: What about longevity of sessions and their endings?
Advantages:
1. You can access the same session state across machines.
2. Same session state is available after reloading the app_pool.
Disadvantages:
1. Slower than in process mode.
2. All objects in the session state have to be serializable.
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.
1 other disadvantage is you probably will have a single point of failure if you do 1 remote state-server across a farm. Even if not a farm, its still worth running locally just to survive app_pool IMO. We got caught up on the serializable part, so do watch that.
Also, keep an eye out for Windows Server AppFabric to release, as it will have a replicated / distributed state server replacement. Supposedly RTM in 1H2010.
I'd say one of the big disadvantages of using In_Proc is that session state can be lost if the app pool or domain is recycled. This can happen any time, for instance if the server is low on memory etc. I personally never rely on In_Proc session for anything you don't want to lose. I've spent hours debugging sites with sporadic problems only to find it was because session state was being lost due to a server that was low on resources recycling (and, of course, the more you store in session the lower the more server resources you use up. Remember, if it can go wrong then it probably will go wrong at some point!
That's why I now normally use State Server for anything but trivial session data. The only real disadvantage I've found is you need to mark classes as serializable, but this is usually trivial. It's also a bit slower, too, but that is negligible in most cases.
There's a good article about this on the IIS MSDN blog.