Published: 06 Nov 2006
By: Karl Seguin

The Session and Cache objects each have their own advantages making it tricky to know which to use for a given piece of data. SessionCache is a simple class meant to bring together the best of both worlds.


When it comes to storing data, .NET developers have a veritable arsenal at their disposal. Aside from the System.Data, System.XML and System.IO namespaces, ASP.NET developers can store data in 5 main places: Application, Session, ViewState, Cache and Context. Each of these mechanisms have their own unique characteristics and uses. The main thing which separates most of them is their scope - some are long lived, some are short live, some are shared amongst all site users, others aren't.

In most cases, it's pretty clear when to use the ViewState and Context objects (although the Context object is generally underused by developers). It's also clear when data should be available to all users (Application) or is user-specific (Session). What isn't always clear is when the Cache object should be used rather than the Application or Session objects.

Cache Object

By default, the Cache object has the same scope as the Application - data stored in it is globally accessible to all users. It's quite easy, and common, to use the Cache to store session data. This is typically done by joining the cache's key with an id that's associated with a particular user, for example:

Memory Friendly

What really makes the Cache object unique (since it clearly isn't its scope), is it's respect for system resources and flexibility. Specifically, both the Application and Session objects practically pin their data in memory. The Cache on the other hand uses a WeakReference, which behaves quite differently. For the most part, storing data in the Cache doesn't guarantee that it'll be there - even for a second. If necessary, .NET will dump items from the cache to free up memory - and believe me, if .NET needs to start freeing up memory, you want to let it do whatever it has to. I've worked with developers who thought they could manage memory better than .NET, the result of this hubris has typically been OutOfMemoryExceptions.

That's why whenever you retrieve a value from the Cache, you have to make sure it's not null. On the other hand, data stored in the Application or Session is going to be there when you pull it out. If you've used the Cache before, you are probably familiar with this type of defensive coding:

It might seem like a nuisance, but the benefits are worth it. In 95% of the cases, the Cache object is better to use than either the Application or Session objects. In some cases you'll have a relatively light chunk of data which is expensive to calculate/fetch/deduce. In this case, pinning data in memory might be an ideal solution. Even in those cases though, items inserted in the Cache can be marked with High or even NotRemovable priority.


Aside from not being harmful to a system's stability, the Cache object is more flexible and powerful than either the Session or Application object. The ability to specify an absolute or sliding timeout, file or database dependency, callback method and a priority are all unique to the Cache object. The only thing the Cache object doesn't have is the ability to specify where the data is stored - it's always in-memory. As you probably know, it's possible to configure the Session to use either memory, state server or SQL Server - although this has to be configured for the entire application.

Not Web-Related

Finally, the last benefit the Cache object provides is that it can be safely used outside of a web context. If you have a class library, say for your business layer, you can reference System.Web and use HttpRuntime.Cache. Some developers have a hard time doing this within their Business layer, but it's completely safe. In all honesty, Microsoft should consider moving the Cache object outside of the System.Web assembly to help developers get over the shock of seeing System.Web references inside a library.

The reference returned by HttpRuntime.Cache is the same which is exposed by the Page property and HttpContext.Cache - so you can use them interchangeably. In fact, HttpContext.Cache actually does:

(Caching data inside the business layer can make it more difficult to effectively unit test code. But there are ways to work around, and even, with it.)


The only problem with the Cache is that using it for session-based information can be a little messy. Always having to append a unique identifier to the key when inserting and retrieving data can be a pain. It would be nicer to encapsulate that within a class and have a clean API to work with. The SessionCache class does exactly that. It's a very straightforward class which simply wraps the Cache object. Here's a partial implementation:

Inside a User Class

If you have a User class within your project, you can even take it a step further and expose an instance of SessionCache as one of its properties. Here's an example:

Consumers can then use a very clean API to store and retrieve user-specific information from the cache:


The Cache object has distinct advantages over both the Application and Session objects. It's more scalable and flexible without any real penalty. The SessionCache is a simple layer of abstraction which wraps the Cache object into a lightweight shell, resulting in code that's easier to read, use and manage when dealing with session-based data.

<<  Previous Article Continue reading and see our next or previous articles Next Article >>

About Karl Seguin

Karl Seguin is an senior application developer at Fuel Industries, located in Ottawa, Ontario. He's an editor here at DotNetSlackers, a blogger for the influential and a Microsoft MVP.

This author has published 8 articles on DotNetSlackers. View other articles or the complete profile here.

Other articles in this category

Code First Approach using Entity Framework 4.1, Inversion of Control, Unity Framework, Repository and Unit of Work Patterns, and MVC3 Razor View
A detailed introduction about the code first approach using Entity Framework 4.1, Inversion of Contr...
Exception Handling and .Net (A practical approach)
Error Handling has always been crucial for an application in a number of ways. It may affect the exe...
jQuery Mobile ListView
In this article, we're going to look at what JQuery Mobile uses to represent lists, and how capable ...
Book Review: SignalR: Real-time Application Development
A book review of SignalR by Simone.
JQuery Mobile Widgets Overview
An overview of widgets in jQuery Mobile.

Please login to rate or to leave a comment.