AJ's blog

March 3, 2007

Bury in-proc session state!

Filed under: .NET, .NET Framework, ASP.NET, C#, Software Architecture, Software Development — ajdotnet @ 10:29 pm

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,

kick it on DotNetKicks.com



  1. Of course those problems only arise if you (over)use the session. If we remember that ASP.NET applications are inherently stateless and then we make applications keeping that in mind – there should be no problem. You should never rely on some state being there waiting for you.

    Comment by Michal Talaga — March 6, 2007 @ 10:20 am

  2. There is a fourth valid value for the setting: turn session state off. Might as well be better for the design of your application.

    BTW my opinion regarding process recycling is: If you use in-proc session state and your process gets recycled AND you are not able to handle this issue properly (I would not regard this as a regular condition), your app has a design error.

    BTW: who uses a single webserver (even a single process) for critical applications? Or do you loadbalance on webservers with inproc session state?

    Comment by Ocho — March 23, 2007 @ 12:32 am

  3. Thanks.
    This explain why we got those random session problems.

    Comment by K3Z — May 27, 2008 @ 5:16 pm

  4. […] funktioniert prinzipbedingt nicht fehlerfrei. Hintergründe finden sich hier. Wer noch den In-Proc-Mode einsetzt, sollte schleunigst wechseln – aber bitte nicht kurz vor dem […]

    Pingback by ASP.NET Session State mit SQL Server In-Memory (neu) - SDX AG — December 14, 2015 @ 12:44 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: