If you’re an ASP.NET developer, you’re certainly familiar with the HttpApplicationState object where you store data for your entire application. Unlike HttpSessionState, the HttpApplicationState object will store that data while your application is running, while the data stored in the HttpSessionState object is destroyed when the session ends, ie the user logs out or has been idle 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 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”];
Request[“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 noticing strange behavior. Sometimes you get the correct number of hits the next time you find a zero or a number that is much smaller than expected.
To understand what’s going on, you need to know how IIS treats your web application.
In fact, you don’t control the lifecycle of your application, IIS does. At startup, your app won’t run until your app’s first web page request hits the server. IIS then 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. 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 it contains, meaning you will lose count on 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 the same process will handle all http requests. This way, IIS won’t 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 the properties page for your application. On the Home tab, click Settings and select the Performance tab. There you can set the “maximum number of worker processes to 1”.
- Use a database to store all the important information. This solution is best when information needs to be stored and outlast the application lifecycle. 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 is better not to rely on it to store data for the entire application, but to use the database to store it effectively and permanently.