I came across an application I had written a while back that was using Application (HttpApplicationState) to manage state across a web application. That little voice in my head that asks, "why?," forwarded me onto a new tangent of thought, asking "why am I using Application and not Cache?" So there I went, off on a new journey in search of the answers to questions unknown (I hope you caught that John Denver lyric, "Calypso").

In reading up on the two methods of state management, cache comes out ahead once again. I pulled a number of sources, but two were the most compelling. One article is actually a chapter from a book, Essential ASP.NET With Examples in C#, by Fritz Onion. It seems like every ASP.NET question I have had, Fritz has answered. The second source comes from a book, Caching and Managing State in ASP.NET Applications, by Xavier Pacheco. I will summarize the points I found interesting about Cache versus Application.

After reading these articles, I think I am going to have to return to a few of my applications and make sure I am using Application only when it is necessary.

According to Fritz Onion:
Pros: Application (HttpApplicationState) is global to the application and shared across all clients.
Cons: If overused it limits scalability, it is not shared across multiple machines in a web farm, nor multiple processors in a web garden, and its primary purpose is subsumed by Cache in ASP.NET.

"Application state is something that should be used with care, and in most cases, avoided altogether."

"Unreliable place to store data, because it is replicated with each application instance and is not saved if the application is recycled."

"In almost every scenario that would have used application state in a traditional ASP application, it makes more sense to use the data cache in ASP.NET"

"Probably the most compelling advantage of the data cache over application state is memory utilization. If the memory utilization of the ASP.NET worker process approaches the point at which the process will be bounced automatically (the recycle limit), the memory in the data cache will be scavenged, and items that have not been used for a while will be removed first, potentially preventing the process from recycling. If, on the other hand, data is stored exclusively in application state, ASP.NET can do nothing to prevent the process from recycling, at which point all of the application state will be lost and must be restored on application start-up."

According to Xavier Pacheco:
It might appear that there are close likenesses between the Cache and HttpApplicationState classes. Both have the capability to store data in an application-wide context, and the syntax for dealing with them is basically identical. The differences, however, are great.

Both the Cache and HttpApplicationState classes provide a mechanism for storing application-wide data and can be used for managing state because of this. This is where the likenesses end.

The Cache class takes management of this data further than that of the HttpApplicationClass.

First, accessing data in the Cache class is fully thread-safe. This is unlike the HttpApplicationState class, which requires you to surround data access with synchronization methods Lock() and UnLock().

Second, the Cache class, based on a prioritization scheme, can free data from the Cache when it has not been used in order to free up memory when resources are low.

Also, you get more control over the items added to the Cache by setting absolute and sliding expiration policies.

Last, you can associate items with the Cache to other cached items or to a file, which will result in the cached items being removed from the Cache.

The HttpApplicationState class serves well as a general state store for information needing to be available application-wide and needing to exist during the life of the application.

The Cache class is better suited for complex state management in which greater control over the cached data is required.