One common approach to enabling high performance web applications is to cache data that does not change frequently. SharePoint is no different in this and provides a host of caching options including blob caching, list item caching, object caching and of course the normal ASP.NET cache. This last caching infrastructure has the focus today. For that entire infrastructure I want to focus on only a small part of the equation; cache invalidation. Usually my preferred approach is to invalidate the cache when the data changes and reload the cache when the data is accessed. In essence this is not so difficult. Simply call Cache.Remove and later on do a Cache.Insert right? While this works for small deployments, as soon as you start to use some of the scaling features of SharePoint you bump into issues. What if you have extended your web application into multiple zones? What if you have multiple web servers? In both cases you will have to deal with multiple caches since each server / zone combination utilizes its own cache. The Cache.Remove code would only invalidate the cache on a single server, in a single zone! This article provides an elegant solution for invalidating a cache across the entire farm.

Code for this article.

It's about context!

At the core the issue is simple. You have multiple HTTP contexts, one per server/zone, each with a separate cache. Your code usually executes in only one of them. We want the code to execute in all contexts so that the cache gets invalidated everywhere. One approach that is almost entirely built-in to the caching infrastructure of ASP.NET is to use a dependency on a file. In ASP.NET you can make use of the native Windows ability to notify your application that files have changed. The ASP.NET cache makes use of this ability to allow cached data to be invalidated when this happens. Typically the scenario is that you load a file from disc into the cache and then monitor changes on that file to invalidate the data. However, you can also make use of this native ability to invalidate the cache in every zone on every server by placing the file in a file share and configuring the cache with a UNC path. You can have each server listen to the same file and hence update all caches at once. The upside to this approach is that it is already implemented for you. There is very little code required. There are also slight downsides to this approach. You will have to create a file share with your solution, something you cannot do natively with WSPs. You will have to configure the location of this share so you code call Cache.Insert with the right parameters. You will have to think about on what server to create the file share. This makes one server more special than another. This could potentially become an issue when changing the farm topology. Next, some organizations I work for have pretty strict rules around creating file shares, meaning, that it is not allowed to create any. One last note about this approach is that granular refreshes become more difficult. You'll want to differentiate between the various pieces of data you cache and only invalidate some of it. You could for instance use one file per type of cached data or similar constructs to provide the granularity. It's not so pretty though!

A new approach to an old problem

Recently I have developed another approach which alleviates many if not all of these issues. The approach involves notifying each HTTP context of a change in the cached data by simply sending a request to a known HTTP end point that runs within that context. The code running at that end point can simply perform the Cache.Remove to remove the changed data. There is one big concern with this approach and that is load balancing. If you have multiple front end servers and you send your HTTP request to a host such as http://intranet or http://www.contoso.com how do you ensure you hit all the servers? Through load balancing all your requests might go to a single machine! The simple solution to this issue is to craft a better HTTP request. You can send an HTTP request to the IP address of a single server to work around any load balancing. By applying the HOST header you can still target the correct IIS web site hosted on the server and hence call into the right context.

Let's go!

In this demo the first step is to create a well-known HTTP end point for your cache invalidation code to hit. A simple HTTP handler will do just nicely. Notice how we can simply access the HTTP context and the cache from the HTTP handler.

public class InvalidateCacheHandler
    : IHttpHandler
{
    public bool IsReusable
    {
        get { return true; }
    }

    public void ProcessRequest(HttpContext context)
    {
        context.Cache.Remove("TestKey");
        context.Response.StatusCode = (int)HttpStatusCode.OK;
    }
}
Now that we have our end point defined the next step is to ensure that the HTTP handler is actually called on each server and for each extended zone. For this we need to retrieve the host name or IP address of each server, all the zones and craft a HTTP request for each of combination of the two.

Given a web application, we can start to build out this code.

void InvalidateCacheForWebApplication(SPWebApplication webApp)
{
}

First, we use the web application to access all the servers in the farm. This gives us the host name of each server, which might be an IP address. Although not entirely necessary the code translates each host name into an IPv4 IP address using the power of a little .NET and the System.Net namespace.

IEnumerable<IPAddress> serverAddresses = webApp.Farm.Servers
    .Where(server => server.Status == SPObjectStatus.Online)
    .SelectMany(server => Dns.GetHostAddresses(server.Address))
    .Where(ip => ip.AddressFamily == AddressFamily.InterNetwork);

Next, enumerate over each zone and over each IP address. This is the matrix to where we must send HTTP cache invalidation calls. Note that we might hit a single server twice if it has more than one valid IP address. Oh well…

foreach (SPAlternateUrl zoneUrl in webApp.AlternateUrls)
{
    foreach (IPAddress ipAddress in serverAddresses)
    {
    }
}

Inside the double loop we craft the HTTP call. We want to send the HTTP request directly to a specific server. The server will then identify the right IIS web site using the HOST header. This means we must setup the host header for the HTTP request, which, I am afraid, is not supported in .NET 3.5. The common workaround is to use the HttpWebRequest.Create method to set up the HOST header and then use a WebProxy class to configure the destination for the request. This combination will send the request to the right server and to the right IIS web site on that server.

UriBuilder ipUri = new UriBuilder(Uri.UriSchemeHttp, 
    ipAddress.ToString(), zoneUrl.Uri.Port);
UriBuilder hostHeaderUri = new UriBuilder(zoneUrl.Uri);
hostHeaderUri.Path = "_layouts/CooleCacheCode/InvalidateCache.ashx";
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(hostHeaderUri.Uri);
request.UseDefaultCredentials = true;
request.Proxy = new WebProxy(ipUri.Uri, false);

After having crafted the HTTP request we need to, well, request the data. We can use the HTTP response code to see if the server answered and therefore has invalidated the cache.

try
{
    HttpWebResponse response = (HttpWebResponse)request.GetResponse();
    if (response.StatusCode != HttpStatusCode.OK)
    {
        // something wrong 
    }
}
catch (WebException)
{
    // something really wrong 
}

Kickass! We now have the code to invalidate caches across our entire server farm. A big benefit is that changing topologies means exactly no change to this code. There is no chance of someone accidentally deleting the file share and we now also have the power of adding granularity to the code by using HTTP query strings to identify the cached item that should be invalidated. All in all a pretty sweet solution!

Hope it helps!