ASP HttpApplicationState and IIS

If you’re an ASP.net developer, you’re certainly familiar with the HttpApplicationState object in which you store application-wide data. Unlike HttpSessionState, the HttpApplicationState object will store that data for as long as your application is running, while the data stored in the HttpSessionState object is destroyed when the session ends, i.e. the user logs 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 tests successfully on your PC might not work as expected when deployed to the server.

Let’s consider a simple example where you want to count the number of visits to 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 start to notice strange behavior. Sometimes you get the correct number of hits the next time you hit a zero or a number that is much less than expected.

To understand what is happening, you need to know how IIS treats your web application.

In fact, you don’t control the lifecycle of your application, IIS does. On startup, your app will not run until the first web page request from your app hits the server. IIS then loads the application into memory and runs it inside a private process. At this time the application[“hits”] it will be zero. After the first request it will become 1. Whenever the requests reach this same process, the Request[“hits”] continue to grow However, at a certain period of time, IIS decides to create another process for your application. You now have two processes running, each with its own copy of Application[“hits”]. So if the value of the application[“hits”] in the first process the Application value is 100[“hits”] in the second process it will be zero!

Also, if a process appears to be idle for a certain period of time, IIS will kill it and destroy all the information in it, which means you will lose account in the application.[“hits”].

What you need to learn is that the HttpApplicationState object is unique per process, as long as 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 problem you have two options:

• Force IIS to maintain only one process for your application, which means that the same process will handle all http requests. This way, IIS will not create additional processes to handle new requests. This solution works only for transient data that doesn’t have to live beyond the lifetime of your application. But performance will suffer if the number of hits increases significantly, because IIS won’t be able to create another process to handle them. To configure IIS, open the IIS console, expand the application pool, and open your application’s property page. On the Startup tab, click Settings and select the Performance tab. There you can set the “max number of worker processes to 1”.
• Use a database to store all the important information. This solution is best when the information needs to be stored and survive the life cycle of the application. It is also useful even if multiple processes of your application are created at the same time.

As you can see, the HttpApplicationState definition can be misleading when considered without the IIS configuration. It’s better not to rely on it to store application-wide data, but to use the database to store it effectively and permanently.