ASP.Net HttpApplicationState and IIS

If you are ASP.net developer you certainly know about the HttpApplicationState object in which you store application wide data. As opposed to HttpSessionState the HttpApplicationState object will store those data as long as your application is running, while those stored in the HttpSessionState object are destroyed when the session ends i.e. the user signed out or has been inactive for some time.

However, this is the theory. The reality is not as simple as that. In case you plan to use the HttpApplicationState object to store information be careful because what is successfully tested on your PC might not work as expected when deployed on the server.
Let’s consider a simple example in which you want to count the number of hits on your website. You will do something like this:

int cnt = (int)Application[“hits”];
Application[“hits”] = cnt +1;

You test the code in your Visual Studio and everything works perfect. But when you deploy it to your server you begin to notice weird behavior. Sometimes you get the right number of hits the next time you will find a zero or a number that is far less than the expected one.

In order to understand what is going on, you should know how IIS deals with your web application.
As a matter of fact, you do not control the life cycle of your application, IIS does. At start your application will not be running until the first web page request of your application reaches the server. Then IIS loads the application into memory and runs it inside a private process. At this time the Application[“hits”] will be zero. After the first request it will become 1. As long as requests reach this same process the Application[“hits”] continues to increase. However at a certain period of time the IIS decides to create another process for your application. Now you have two processes running, each with its own copy of Application[“hits”]. So if the value of Application[“hits”] in the first process is 100 the value Application[“hits”] in the second process will be zero!

Furthermore, if a process appears to be idle for a certain amount of time, IIS will kill it and destroy all the information it contain, which means that you will lose the count in Application[“hits”].

What you have to learn is that the HttpApplicationState object is unique per process provided that this process is still alive. You can be sure that your process will not be alive (running) if it is going to be idle for a long time.

To solve this issue you have two options:

• Force the IIS to maintain only one process for your application, which means the same process will handle all the http requests. This way IIS will not create extra processes to handle new requests. This solution works only for transient data that do not have to live beyond the life of your application. But performance will suffer in case the number of hits increases significantly, because IIS will not be permitted to create another process to handle them. To configure IIS, open the IIS console, expand Application Pool and open your application property page. On the Home tab click configuration and select the performance tab. There you can set the “maximum number of worker processes to 1”.
  
  
  
  

• Use a database to store all important information. This solution is better when the information must be stored and outlive the application life cycle. It is also useful even if multiple processes of your application are created at the same time.

As you can see HttpApplicationState definition can be misleading if considered without the IIS configuration. It is better not to rely on it to store application wide data but use database instead to store them effectively and permanently.