Best practices for 'InProc' vs 'StateServer' for ASP .NET session state

Question

We have a single ASP .NET application running on a single web server (no farm). For now, we're using the default 'InProc' session storage. Is it worth considering using the ASP .NET state service instead? If we went that route we'd likely just run the service itself on the same machine as the application, so making calls out over the network to get and set session info wouldn't be an issue. The reason we are considering this at all is to help avoid session data being lost when the app pool recycles.

Also, using SQL Server is off the table for now, so we're just talking about in-process vs state server.

What are the pros and cons to each mode in this scenario?

Answer 1

Well the state server is a little slower than in proc. The benefit you will get out of it is that if you need to recycle the app pool, then the state of the application (user sessions etc.) will be unaffected. If you plan on using a state server in the future, I would start using it now. With in process, objects are stored in memory as is, but with the state server they are serialized. This can be a big deal if you plan on making the switch later as you'll have to check that everything you store in state is serializable. If you start out with that restraint, you know up front (while you're actively working on that module) what is going to work and what isn't.