Stats

Data Caching

Unified algorithm for caching data retrieved from a backend repository.

Introduction

Data retrieving from a repository can be quite a “heavy” task from a performance point of view, especially when the data repository is located far from the application server (e.g., web service call, RPC call, Remoting etc.) or some specific data is accessed very often. So, in order to reduce the workload and time for data retrieving, you can use a caching functionality.

There are some rules that you should be aware of:

Use caching of data for a small period of time and avoid caching for the whole application lifecycle.

Try to cache the data that is likely to not be changed very often (e.g., dictionary elements).

Some data repositories can support notification events if the data is modified outside of the application (e.g., the data is just stored in a file).

Besides the obvious goals, data caching has some pitfalls (all of them are about potential situations when cached data can expire and application uses inconsistent data):

If the application is going to be scaled to a distributed environment (web farm, application cluster), then every machine will have its own copy of cached data. So, one of the machines can modify the data at any time.

Several applications can access the same data repository.

There are very many different implementations of the caching functionality, but all of them have a lot in common. I will use the “Microsoft Enterprise Library Caching Application Block” and will present you a way of simplifying the usage of the caching functionality.

My implementation of the caching functionality can be divided into two main parts: the cache manager utility and its usage. It heavily uses anonymous methods and generic methods (new features of .NET 2.0).

CacheService is a manager utility that is implemented as a singleton wrapper for underlying the MS caching API. It grants a few methods (GetData<t>, Add, Remove).

As you can see, the usage of the caching functionality is quite simple. And, you can use any appropriate code in your application architecture inside the anonymous method so that it would be easy to add caching support to your application.

All you need is:

Declare a synchronization object that will be used to synchronize access for the cached data;

Define an expiration timeout;

Use an anonymous method that must match the GetCachedObjectDelegate (remember that anonymous methods can access all the variables that are available in its outer method; actually, the C# compiler creates a new class definition that has all the variables as fields, and both the methods are just instance methods).

This implementation of the caching functionality can also be used for application scope caching. But, with a little effort, it can spawn the functionality for caching data at session or request scope.

Actually this article is aimed to describe some kind of a wrapper functionality so that its users (developers) will not have to know anything about underlying caching functionality implementation. So that it can wrap as enterprise library caching implementation, HttpRuntime.Cache or even any third party implementations.
Main benefit of this implementation is that it gives a very easy usage of a caching strategy by just using anonymous methods.
By the way this article uses MS Enterprise Library Caching block as underlying implementation. Yesterday I have added a source code sample application (it will available when codeproject authority confirm my modification).