Home » ASP.NET » The case of the disappearing session variables

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

 

Other post in ASP.NET

Related Post

  • Storing a DataRow into a Session (server) variableStoring a DataRow into a Session (server) variable I recently ran into a situation where I needed to store a DataRow object, which is not serializable, into a Session variable using the Session Server.  As I mentioned yesterday, all […]
  • ASP.NET JSON  and ViewStateASP.NET JSON and ViewState I received the following question recently about my article "ASP.NET AJAX using JSON - Here’s how." If we update the value of a textbox or label via a JSON web service call - will the […]
  • Multi-Step Processing in ASP.NETMulti-Step Processing in ASP.NET I received the following question a few days ago but I’ve been so busy with billable work that I just haven’t had a chance to answer it until now.  Actually, I’m still busy, but I […]
  • ASP.NET Web Design SoftwareASP.NET Web Design Software What if there was a product that would allow you to create your web site themes as easy as you could create a PowerPoint presentation theme?  Wouldn’t that be cool?This past weekend I […]
  • GridView and Updating A Row ManuallyGridView and Updating A Row Manually A couple of days ago I mentioned a project that I’ve been working on that is a bit out of the ordinary as far as GridViews go.  One of the issues I’ve had is that the edit template […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback