It shouldn't come as a surprise to anyone when I say that our Production environment is load balanced. I have mentioned this before and I will be mentioning it again in the future. But, for those who may have missed my previous tirades, let me explain the impact of load balancing on Session State.
One of the features of ASP.NET is to store information specific to a browser session (aka user) into something called Session State. Session State is kind of like the junk drawer you have at home where you have batteries, twist ties, plastic spoons, stud finders and assorted other "stuff". Session State allows you store what you need to store in order to keep track of where the user is in the application and what data you need to save on their behalf. The next time the user accesses the application the session state is automatically loaded and you're ready to rock.
There are a number of places to store session state: In Process, Out of Process or in SQL Server.
In Process means that Session State is going to be stored in the Application Pool running the web site. So, if the application pool recycles, all session state is going to be lost. A number of projects currently use this method and are in danger of losing Session State, if they use Session State, as we use Application Pool recycling to solve a number of application issues. In addition, if, for some reason, BigIP sends the user to a different web server to service the request then the Session State is not going to be present, potentially causing a number of application failures to occur
Out of Process is where the session state is hosted by ASP.NET in a different process, potentially on a different machine. While somewhat safer than storing it in the same Application Pool, a problem arises if this service needs to be reset whereby the Session State is again lost. Indeed, if the process is hosted on the same server as the web site, moving the request to another part of the load balanced cluster is going to be a problem as Session State will not be available for the request. If Session State is stored on a separate machine then the biggest problem is that of durability of the data. Any problems with the service may wipe out all session state for all machines.
Storing Session State in SQL Server is the slowest method, but is by far the safest method for durability and the best method when utilized in a cluster. Each request for Session State goes out to SQL Server to ensure that the latest and greatest version of Session State for that user is retrieved and used.
In our environment we have asked people to use SQL Server Session State, and yet, by looking trough the web.config files of a number of projects I've noticed that they have their Session State set to In Process. If Session State is actively being used, this is a recipe for disaster. I urge each project team to take a quick look at their web.config files and change it to use SQL Server instead of In Process. Even if you don't currently use Session State, you may in the future and this will prevent you from having a nasty accident.
No comments:
Post a Comment