Bury in-proc session state!

In ASP.NET session state can be held in 3+ locations. The choice is between in-proc (i.e. managed in the app domain), out-of-proc (with either ASP.NET state service or in SQL Server), or custom built.

When you create a new web application, in-proc is used by default – which is the worst choice one could make. Apparantly this is the case for simplicity, because it does not need additional setup and works out of the box. ASP.NET state service needs a running service (which is by default not the case), and SQL Server or custom built solutions obviously need even more setup work.

What you should do immediately is to switch to out-of-proc mode!

Why? Well, not for the usually mentioned reasons. Not because using out-of-proc session state increases robustness, i.e. the state will survive if the application restarts, allegedly after some kind of error. Not because MSDN advises against in-proc session state for web garden scenarios (see „caution“). And also not because there is a serialization issue (see „note“).

Don‘t get me wrong, those are all valid reasons. Especially the serialization issue is the very reason why you should use out-of-proc mode right from the beginning rather than switching later. But the reason you should switch is more simple and evene more serious: In-proc session state does not work!

„Are you nuts? I always used it and never had any problems…“. Yes I know. But sorry, you were just lucky. Just because the problem didn’t manifest itself doesn’t mean you didn’t have it. Actually Microsoft tells all the facts one needs to know (they just forgot to tell about the consequence):

„The worker process is subject to a feature named process recycling. Process recycling consists in the aspnet_isapi ability of automatically starting a new process when the existing one is consuming too much memory, responds too slowly, or just hangs. When this happens, new requests are serviced by the new instance, which becomes the new active process.“

And what happens to the in-proc state? Right. Nothing. In other words it dies with the app domain. Session state lost, sorry. And by the way, this is by intention.

„OK, I can allways switch in production, no big deal!“ Yes you can. But don‘t make too many plans for the weekend, you might have to track down that serialization issue. That one is particularly nasty, because it happens out of sync. You can put anything from integers to objects to french fries into the state. ASP.NET just won‘t complain. Only at the end of the request life cycle the session state is serialized and only if some non-serializable object is in the state you (or rather the end user) will be „served“ with a serialization exception. Try to find the root cause for that exception in a non-trivial application and without knowing what the user did beforehand.
Therefore you should wok out-of-proc during development. If you did not do that you are probably better off with in-proc session state and loosing the sessions now and then.

That’s all for now folks,
AJ.NET

Advertisement