Cache and security trimming in Sharepoint

If you use cache (I’m talking about not only standard ASP.Net cache, but cache in general) in the Sharepoint web application, you should keep in mind that users with different permissions may see different content on the site. E.g. if you crawl site and all its sub sites for the documents which are tagged by particular managed metadata term in the custom web part and want to speed up the process by adding caching, you should wonder does current user have access to the particular document before to show the link to this document even if it comes from the cache. Often developers forget about it.

Consider the following example: user A with administrative permissions comes on site – web part crawls the sub sites, stores result in the cache and display them in UI. Then user B with reader permissions comes on the same site. If web part will use cache which was filled for user A, then user B may see documents which he can’t access. The issue can be solved by adding SPContext.Current.Web.CurrentUser.ID to the cache key, so different users will have own cache. If you wonder about amount of users, you may use more common identifier – e.g. group id for he users with similar permissions. In this case users within one group will use the same cache. For those users which belong to several groups – you should rather create cache for each possible combination of the groups or use cache of the most powerful group.

Using of ASP.Net Cache in Sharepoint farm environment

Often in order to improve performance of Sharepoint web application developers use standard ASP.Net
in-memory Cache (see HttpContext.Cache). As cached objects reside in memory of appropriate AppPool
it works very fast. However you should be aware about potential problem with using of ASP.Net of
multiple web front ends environment. In Sharepoint world farms are often used in production. At the
same time single-server environment is commonly used for development. The problem that in this case
behavior of the ASP.Net cache may differ from your expectations.

As I already said cached objects are stored in the memory of AppPool inside w3wp process. If you have
multiple WFEs – each will have its own IIS installed and w3wp process. So there will be several different
unsynchronized caches on different WFEs.

Consider the following scenario. Suppose that we have a farm with 2 WFEs:

1. User makes request and NLB routes it to WFE1
2. Some code is executed on WFE1 and result stored in the cache (with specified expiration life time)
3. After that the same user makes the same request and NLB now routes it to WFE2
4. As WFE2 doesn’t has access to the cache of WFE1 – the code is executed again and result is
   stored to the cache of WFE2. This result can differ from the data which is stored in the cache of
   WFE1
5. We have unsynchronized cache on both WFEs. It means that user may see different information
   based on NLB routing

In order to avoid such situations you need to use distributed cache system:

1. memcached
2. NCache
3. Windows Server AppFabric cache (Velocity)

In this case you will avoid problems with unsynchronized caches.