3
votes

The past days I've been working with Azure Caching. Good practice is to use the local cache functionality to prevent roundtrips to the distributed cache.

As can be read in the documentation; when you make a call to dataCache.Get(...), the application first checks if a version in the local cache is available and, if not, the object is retrieved from the distributed cache. The problem is that the local version can be older than the distributed version of the object. To solve this problem, the method 'dataCache.GetIfNewer(...)' is available that can be used to check if the version of the local object differs from the distributed version and, if it does, it returns the new object.

So far, so good...now my questions; I've created two seperate applications (app A en app B) to test the Azure Caching mechanism. Both applications run on two different (physical) locations so they both have their own local-cache but they both use the same distributed cache.

Is it true that something has changed in the process of invalidating the local cache? I've tested the following scenario and found out that the local cache is update automatically:

  • App A stores the value "123" in the distributed cache using the key "CacheTest"
  • App B uses the dataCache.Get(...) method to retrieve the object for the key "CacheTest" which cannot be found in the local cache so it is retrieved from the distributed cache en returns the object with value "123".
  • App A changes the object with key "CacheTest" to the value "456"
  • App B uses the datacache.Get(...) method to (again) retrieve the object. Because the object should be in the local cache, I would expect the value "123" but it returns the new value "456"!

How strange is that? Is something changed in Azure Caching lately? And yes...I'm sure that I've turned on local caching and yes, I've set the time-out on the local cache to 3600 seconds (1 hour).

Can somebody confirm that Azure Caching has been changed?

Edit for Nick: So what you're saying is that the next lines of code that I've found on a Dutch Microsoft site are nonsense? When the local-cache is updated automatically, there's no need to call the 'GetIfNewer' method: http://www.dotnetmag.nl/Artikel/1478/Windows-Azure-AppFabric-Caching

/// 
/// Ensures that the newest version of a cached object is returned 
/// from either the local cache or the distrbuted cache.
/// 
public TCachedObjectType GetNewest<TCachedObjectType>(string key) : 
   where TCachedObjectType : class
{
DataCacheItemVersion version;

// Gets cached object from local cache if it exists.
// Otherwise gets cached object from distributed cache and 
// adds it to local cache.
object cachedObject = cache.Get(key, out version); 

// Gets cached object from distributed cached if it is newer
// than given version. 
// If newer it adds it to local cache.
object possiblyNewerCachedObject = 
     cache.GetIfNewer(key, ref version);

if (possiblyNewerCachedObject != null)
{
    // Cached object from distributed cache is newer 
    // than cached object from local cache.
    cachedObject = possiblyNewerCachedObject;
}

return cachedObject as TCachedObjectType;
}
1

1 Answers

1
votes

If the described behaviour is the same as appfabric velocity, the behaviour described is as expected. When local caching is enabled it means that when a given node requests a cache item from the distributed cache, it asks the distributed cache what the current version is. If the locally cached version matches the distributed version, it returns the data from the local cache. If not, it retrieves the latest value from the distributed cache, caches it locally and then returns it. The idea is that if any node updates the key, all nodes will always be ensured to get the latest version even if appfabric had already cached them locally. The distributed cache keeps track of the latest versions and where their data is stored.