Beware of lost sessions and logins on IIS 6 due to web gardens and in process session state

If you're using IIS 6 and enable the "Web garden" feature (setting the max number of processes for that pool to greater than 1), beware. You may suddenly "lose" sessions or experience "random logouts". The problem has to do with .NET's in-memory session state and web gardens. You may not even know what web gardens are, but if someone else can tweak your IIS settings, or if you've moved code to a new box, like a QA or prod or hosting box, that's configured this way, and this starts happening, this could be the cause.

Of course, the problem could also be caused by rather well-documented instances of the application domain or worker process recycling. You can set up Performance Monitor to watch if that's the issue. But I was experiencing the problem and this was NOT the issue. I finally figured it out.

In my case, the application pool for my asp.net apps had been changed to enable more than 1 worker process (app pool>properties>performance>web garden>max number of worker processes).  This creates multiple w3wp.exe processes to which the web app's requests can be handed. This "web garden" configuration seemed logical to the IIS administrator.

But the problem was that we were also using the default .NET feature of storing sessions in memory (in process). So a user would get put onto one process for some number of requests with their session, but then they'd be rolled over to another process at some point (seemingly randomly) and that new process would not have the session there.

So the user either finds the session "gone" or they're logged out (if the app relies on sessions for tracking logins).

Once you understand it, it makes perfect sense. But the problem is if you don't even fathom this, and judging from other entries on the net, many are suffering this and haven't figured it out.  I hope this will help them.

Solutions

You can solve the problem either of a couple ways. First, you can set the app pool to have just 1 process. (This is also the default, and some have found the problem "solved" when they create a new application pool. It's just that they're going from greater than 1 to just 1.)  Of course, you may have justifiable intentions by creating multiple processes per web app.

In that case, you simply can't rely on in process state management and must switch to StateServer or SQLServer (in the web.config or machine.config). See any of many resources on how to change that. (BlueDragon users can find this discussed in our "Deploying CFML on ASP.NET" manual.)

But this problem can definitely affect more than just BlueDragon users. I offer this in hopes of saving others the heartache I/we suffered. (BTW, BlueDragon customers may experience this by noticing that the BD admin console logs them out unexpectedly. Again, it could be caused by the other reasons I mentioned above about the application domain recycling. Again, that's covered in the BD.NET manual.)