Invalidate portions of the asp.net mvc output cache - with varying levels of granularity

Question

I'm a little confused about the granularity offered by the HttpResponse.RemoveOutputCacheItem() call. I'm interested in performing some output caching on dynamically-generated images, and would like to vary the output cache using at least to paramaters (let's call them 'id' and 'size' for argument's sake).

So, for example:

/Image/User?id=1
/Image/User?id=1&size=1
/Image/User?id=1&size=2

Would be cached seperately.

When a given user changes their picture; I would want to invalidate all output cache items for that user id (regardless of size). This question answers my question about a single particular parameter. But..how would I go about flushing all cached responses for a user without regards to the size param? (Let's assume I wouldn't know all of the possible values of 'size' ahead of time).

I'd ideally like to do something like:

HttpResponse.RemoveOutputCacheItem("/Image/User?id=1&size=*"); //wishful thinking

Can anyone point me in the right direction?

Edit

@JcMalta proposed a promising solution, however I can't find an appropriate collection that is exposed for items in the output cache. A viable solution might include an operation similar to what he proposed if this exists somewhere.

Answer 1

Really this is off the top of my head ... but perhaps in the right direction:

public void ClearCache( string myImagePrefix)
{
    var cache = System.Web.HttpContext.Current.Cache;

    IDictionaryEnumerator enumerator = cache.GetEnumerator();

    while (enumerator.MoveNext())
    {
        string key = enumerator.Key.ToString();
        if( key.StartsWith( myImagePrefix)
           cache.Remove(key);
    }
}

Answer 2

The output cache has a concept of "cache dependencies" that might be what you're looking for.

.NET has a FileCacheDependency which means a cache item is automatically invalidated if a file on disk changes, and an SqlCacheDependency which invalidates objects when data in an MSSQL database changes. You can also write custom cache dependencies.

HttpResponse has a bunch of methods named Add*Dependency/ies to let you use this.

For example, if your images were based a file on disk, your handler serving the resized image could say:

HttpResponse.AddFileDependency(@"C:\images\user" + userId + ".jpg");

This registers a dependency for your response. When your response gets added to the output cache, any dependencies go along with it. When a dependency changes, the cache item is automatically invalidated.

If your images are based on files or SQL data, this might work for you out of the box.

You can also use HttpResponse.AddCacheItemDependency to have one cache item dependent on another cache item. If you know your original image URL "/Image/User?id=1" will always be cached, then you could make the resized images depend on the original, and HttpResponse.RemoveOutputCacheItem() on the original will clear all of them. If the original image isn't always cached (maybe no-one has requested the original, only the thumbnails), then I don't think this will work.

The reason the built-in cache dependencies work is that both Windows and SQL Server have built-in APIs to notify changes to files or data. The built-in cache dependencies are wrappers around these. But if neither of these is suitable, your last approach is to implement a similar thing for your own purpose.

The basic idea (untested) is to subclass CacheDependency, let's call it PictureCacheDependency.

You need to set up some sort of listener/observer pattern so that when a user edits their picture, the picture editing code can tell any relevant PictureCacheDependency objects that the picture has changed. When that happens, the PictureCacheDependency should call base.NotifyDependencyChanged, and the framework will take care of the rest.

You'd probably have the PictureCacheDependency constructor register itself in a static dictionary of events, using the user ID as the key. However you approach it, be sure to override CacheDependency.DependencyDispose to free up any references, otherwise you'll leak memory.