is application state = system.web.httpcontent.cache ?

Question

Is application state (http://msdn.microsoft.com/en-us/library/ms178594.aspx) the same as using the System.Web.Caching API?

i.e.

System.web.httpcontent.current.cache[somekey] ?

Answer 1

No, they are not the same.

The ASP.Net Cache object is specifically optimized for caching content or objects that are short lived or can live for a defined amount of time. It will be cannibalized by the garbage collector if resources need to be freed up, and it is never guaranteed that something you put in the Cache will be there the next time you look.

System.Application is a global collection of key-values that can be used to store information global to all users in a thread-safe way (as long as you utilize it safely). However, nothing will ever be removed from System.Application unless you explicitly remove it.

Answer 2

You probably mean System.Web.Context, not content, and the Cache is different from HttpApplicationState.

The application state is there for items that remain fairly static for the lifetime of the application (unless explicitly removed). As can be read in the page you have linked from, the recommendation is to use Application:

to store small amounts of often-used data that does not change from one user to another.

Cache is more transient in nature and is supposed to be used for content that has much shorter life (seconds to minutes) and removal of items is managed automatically (dependent on configuration).

Answer 3

The answer is there in your own link. Read it.

However, storing large blocks of data in application state can fill up server memory, causing the server to page memory to disk. As an alternative to using application state, you can use the ASP.NET cache mechanism for storing large amounts of application data. The ASP.NET cache also stores data in memory and is therefore very fast; however, ASP.NET actively manages the cache and will remove items when memory becomes scarce.

Answer 4

It's not the same.

If the data

• is stable during the life of the application
• must always be available and must not be purged

you'd use HttpApplicationState.

If the data

• not necessarily is needed for the life of the application
• changes frequently
• can be purged if needed (for example low system memory)
• can be discarded if seldom used
• should be invalidated/refreshed under some conditions (dependency rule: time span, date, file timestamp, ...)

then use Cache.

Other important differences:

• Large amounts of data may better be stored in Cache, the server then can purge it if low on memory.
• Cache is safe for multithreaded operations. Page.Application needs locking.

See also this article on etutorials.org for more details.

And this question: http://stackoverflow.com/questions/2922171/asp-net-page-cache-versus-page-application-storage-for-data-synchronization/2923560#2923560

Answer 5

Actually I would say that the main purpose of Application state is backwards compatibility with classic ASP applications, and I would never use it in new ASP.NET apps.

As other respondents have indicated, the Cache is actively managed so that data will be discarded if memory is scarce.

Application state is essentially equivalent to a static Hashtable, with locking semantics that are inherited from classic ASP.

If you need to store static data, it's almost always better to store it as a strongly-typed static field of a class rather than using Application state. If you need locking, use the standard synchronisation mechanisms of .NET.