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?
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.
State Server is a great(!) choice to get started with. Why? Because it means that your application is now compatible with any out-of-process storage modes.
If you currently develop your site with InProc and wanted to move into StateServer or SqlServer at a later time, you can have issues with serialization. Not always, but it is does happen.
Some examples include (some already mentioned):
Therefore, its best to get this sorted out sooner rather than later. Its only a config change and a service start; Boom!
What is also means, is if you decide to go down a completely different route of session storage, such as using Redis (Distributed Key/Value Store) or RavenDB (Document Database), you are already sorted.
Its really is a good investment of 1 minute's work. You are now ready for web farms, load balancers and any other session management systems that you decide to prototype against.
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.
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.
Disadvantages of Sessions in ASP.NET
Every variable is stored as Object. That means you need to convert Object to certain type when read session variable.
In addition to this, if session is empty, Object will be null. Before reading session variable, you need to check it for null. Even if variable is initialized before, it could be null because session is expired. An attempt to use null session value could return an exception. If value of session variable is null, common practice is to use some default value instead of meaningless null. If value is not null, you must convert it to appropriate type because all session variables are type of object. When do all this things, you should pay attention to avoid hard coding. More about reading and writing of session variables on scalable and maintainable way you can read in How To Write, Read and Delete Session State Variables tutorial.
Variable name is type of string. If you hard code name of the variable, there is an option to make type mistake somewhere. The problem is, if you try to read session variable that doesn't exist, ASP.NET will not return any exception or warning. It will simply create new variable with wrong name which has null value. These types of errors could be hard to find.
Session data should not be used for storing of sensitive data. There is a possibility that malicious user obtain regular visitor's session id. If session state is used to store information like: "allow access to administration area or not" or something like that, attacker could see website's sensitive data, other's private data, edit database, delete content etc.
If InProc mode is used, sessions easily exhaust all server resources and thus decrease website performances.
StateServer
SQL Server is most reliable of all modes. Session data are intact if ASP.NET restarts, but also if SQL Server restarts.
SQL Server is also most scalable option.
SQL Server is often available in shared hosting scenario
Custom mode
You have complete control over sessions. It is possible to create even custom session id.
You can support different data sources. That could be useful to store session data on other database, like Oracle, MySQL, MS Access etc.
for any other details you can click here to view ASP.NET Session state advantages. hope my answer helped you.! :)
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.