The case of the disappearing session variables

Way back in ASP.NET version 1.1, I wrote one of my first asp.net web sites for a client that depended pretty heavily on session variables. Without getting into the arguments about the wisdom of using session variables in the first place. Let’s just say that we needed to store state information and that session variables were the best way to handle the issue. We spent months working on the web site. Everything worked fine during development and even as we tested the application… on our local computers. But, once we put the application up on the server. A shared server where a lot of other asp.net applications were also living, we suddenly found that the application would work, mostly. But, every once in a while the application would act like it couldn’t find the session variables we were trying to store. Now, we all know that programs do pretty much what they are told. So, the question you start asking yourself in a situation like this, where it works most of the time, is why would this not work only some of the time? Why would the session variable get lost? Well, the little known fact, at the time, is that the ASP.NET worker process recycles itself to take care of all the things that could go wrong. Excessive memory usage, runaway processes, etc… And, when the worker process recycles, all of the in-proc session variables go away. This wouldn’t be a problem, except in-proc is the default in ASP.NET. It still is. However, Microsoft provided two remedies. The Session Server and the SQL Session Server. If you implement either of these, than you could even turn off your computer and turn it back on and the sessions would still be there. Many people still believe that these two servers are only for web farms. But, unless you are running on your own server, you should be using one of these two servers instead of the default, in-proc, server. In fact, I would suggest that even if you are running your own server you should also use a session server of some time. You never know for sure when the worker process will recycle and kill all of your session variables. There are a couple situations that will not work with session servers. One is that you will no longer be able to store COM objects into the session variable. The other is that you will not be able to store any objects that can not be serialized. But, you shouldn’t be storing COM objects in the session variable anyhow and you can make just about any object serializable in one way or another. Finally, because non-serializable object can be stored in an in-proc session store, but can’t be stored into a session server, you should turn on the session server on your development machine and store you session variables into it instead of using the in-proc session server during development. See also: Setting up SQL Session Server in a Shared Hosting Environment