Skip to main content

Distributed Cache and SharePoint 2013

We all know that in version 15 SharePoint is now integrated with AppFabric's distributed cache. There's a Distributed Cache service running on each SharePoint server (with exception of the database ones), AppFabric cache is now configured by SharePoint installation routine, and finally there is a new namespace in SharePoint API: Microsoft.SharePoint.DistributedCaching.Utilities.
 
You could definitely use AppFabric's cache with SharePoint 2010, as long as you create a wrapper class that takes care of cache configuration, cluster and endpoints instances, etc. However, now that the AppFabric's cache is integrated, you would probably expect something as simple as SPDistributedCache.Get(cacheKey). Well, even a quick look at the poorly-documented Microsoft.SharePoint.DistributedCaching.Utilities classes tells you this is still far from being true. Essentially the only benefit you currently get from this API is ability to access the distributed cache configuration, and use it when creating your AppFabric DataCache wrapper class. Yes, you still have to do it, though it became much simpler.
 
In order to get a Microsoft.ApplicationServer.Caching.DataCache object in SharePoint code you need to:

1. Get or create the name of the cache you are planning on accessing. The default SharePoint cache name would look like:
DistributedDefaultCache_<Farm ID GUID>

2. Get or create the name of the cache cluster you are going to access. The default SharePoint cache cluster name uses the following format:
SPDistributedCacheCluster_<Farm ID GUID>

3. Obtain the cache cluster manager. This is where the new API comes handy:
var clusterManager = SPDistributedCacheClusterInfoManager.Local;

4. Get the cache cluster information. The "clusterName" here is the string created in step 2:
var clusterInfo = clusterManager.GetSPDistributedCacheClusterInfo(clusterName);

5. Create a list of cache host endpoints:
var hostEndpoints = new List<DataCacheServerEndpoint>();
foreach (var cacheHost in clusterInfo.CacheHostsInfoCollection)
{
     hostEndpoints.Add(new DataCacheServerEndpoint(cacheHost.HostName, cacheHost.CachePort));
}


6. Get the factory cache configuration, and initialize it with the list of endpoints:
var factoryConfiguration = new DataCacheFactoryConfiguration();
factoryConfiguration.Servers = hostEndpoints;


7. Use factory cache configuration to get the cache factory object:
var cacheFactory = new DataCacheFactory(factoryConfiguration);

8. Finally, obtain the DataCache object to get access to all the typical cache operations, such as Add, Get, Put, etc. The "cacheName" here is the string created in step 1:
DataCache cache = cacheFactory.GetCache(cacheName);

A few advises to keep in mind when working with AppFactory cache:
  • Do not forget to obtain a mutex lock for the DataCache object when performing cache operations.
  • Do not expose the DataCache object as a public property in your wrapper. This will require including a reference to Microsoft.ApplicationServer.Caching in any project that will be using your wrapper.
  • Always set timeout when caching SharePoint content. Even when you're sure it's not going to change. Even when you're certain you've covered all possible events resulting in content updates. There will always be a case or two when some content got removed, resulting in an orphaned cache record.

Comments

Popular posts from this blog

SharePoint 2013 and "search scopes"

While SharePoint 2013 introduced some undeniably handy features in the content discovery department, some of the old functionality has changed so much that you'll have to forget many of the design tricks that worked in 2007 and 2010.  One of such pain points is deprecating search scopes in SharePoint 2013. The requirement Let's start with a trivial situation. You have a requirement that states: "A user should be able to perform different types of search from any page/sub site on the portal by selecting a type of search and specifying keyword(s)". This would be considered an out-of-box functionality in 2007/2010: you just enable search scopes dropdown (considering the search box control is already in the master page), and define scopes. Piece of cake! Well, not so much in 2013.   The problem The thing is - there's no search scopes in SharePoint 2013. OK, to be exact - there's no user-definable search scopes, as we still have a couple of built-in

Navigation Settings in SharePoint 2013 Site Definitions

Who likes creating SharePoint site definitions from scratch? Well, it's not my favorite part of the SharePoint development either. An initially good idea of setting up your whole site through an XML file, received implementation and support far from being perfect. That quickly lead developers to look for alternative ways of defining and provisioning sites, primarily through the SharePoint API. A simple ONET.XML with beefy code-packed features became de-facto standard. What was supposed to be a template became compiled code. I was hoping SharePoint 2013 would at least attempt to do something about it… Tasked with creating a few publishing portal site definitions, I was unpleasantly surprised to find out that any attempt to use my new site definition to provision a site collection root results in both Global and Current Navigation switched to "Managed Navigation" mode, while I needed it to stay in the good old "Structural Navigation" one. This mode is new to Sh