Does Azure AppFabric Output Caching Support Read-Throughs or Programmatic Invalidation?

Question

I'm wondering if what's described in (1) is supported by the output caching providers that currently ship in the Azure AppFabric SDK:

Normally when a get request fails the client is responsible for loading the missing data from slow storage (e.g. a database, file server, or remote service) and populating the cache. This triples the number of round-trips needed for the request and introduces the possibility for a race condition. With Read-Through support turned on AppFabric itself makes the secondary call to slow storage. AppFabric gains this ability via a custom implementation of the abstract class DataCacheStoreProvider.

The "What's Next" section of (3) seems to suggest that it's not:

In addition, the success of the Caching session state provider scenarios with ASP.NET has resulted in requests for the ability to associate write-behind and read-through queries with the cache so that the cache can become the primary way to manipulate data, while letting the associated queries update the data tier in the back end.

We’ll be evaluating these and other features for possible inclusion in future releases of Windows Azure AppFabric Caching. In the meantime, we encourage you to experiment with the current Caching service implementation and let us know how it works for you.

Is there any other mechanism for programmatically a) invalidating and b) replacing a cached page without letting it naturally re-hydrate through client requests (which can potentially cause issues under load, as all requests race to re-hydrate the element)?

Other documented differences w/ Windows Server (4):

ASP.NET Caching

Windows Azure AppFabric provides both a session state provider and an output cache provider. This provider differs from the one that shipped with the first release of Windows Server AppFabric. It also provides additional features. Because of this, it is important to carefully follow the instructions for modifying the web.config file correctly for Windows Azure AppFabric. For more information, see Using the ASP.NET 4 Caching Providers for AppFabric.

Unavailable Caching Features

Windows Azure AppFabric supports a subset of the caching features available in Windows Server AppFabric. The following list describes some of these differences.

Notifications

Notifications are not supported in Windows Azure AppFabric Caching. This also means that you cannot use notifications to invalidate the local cache. In Windows Azure AppFabric, local cache can use only a timeout based invalidation policy. For more information about the notifications feature in Windows Server AppFabric, see Cache Notifications (Windows Server AppFabric Caching).

Expiration and Eviction

By default, items in a Windows Azure AppFabric cache do not expire. This means that when you exceed your maximum cache size, the least recently used items in the cache are evicted. Unlike Windows Server AppFabric, there is no way to change this default expiration setting or value. However, if you add items to the cache with an explicit expiration time, such as 10 minutes, then the cache will honor this expiration value. This can be done with various overloads of the Add and Put methods. Note that the ASP.NET providers automatically use these overloads to provide explicit timeouts for session state and output caching.

Windows Azure AppFabric Caching does not support disabling eviction on a cache. Under memory pressure, it is always possible that items could be evicted. Applications should be designed to anticipate that items might be missing and require reloading at any time. If a cache is too small for the application requirements, it can be dynamically increased from the Windows Azure Platform Management Portal.

For more information on expiration and eviction in Windows Server AppFabric, see Expiration and Eviction (Windows Server AppFabric Caching).

High Availability

Windows Azure AppFabric Caching does not support the high availability feature. For more information about high availability in Windows Server AppFabric, see High Availability (Windows Server AppFabric Caching).

Regions and Tags

Windows Azure AppFabric Caching does not support user-created regions or tag-based searches.

API Support

In most cases, you can use the same APIs to write cache clients that use Windows Azure AppFabric or Windows Server AppFabric. There are some exceptions due to differences between the two solutions. For a detailed review of the APIs available for Windows Azure AppFabric cache clients, seeAPI Reference (Windows Azure AppFabric Caching).

References:

(1) Windows Server AppFabric adds Read-Through and Write-Behind Support: http://www.infoq.com/news/2011/08/AppFabric-CTP

(2) Extensible Output Caching with ASP.NET 4 (VS 2010 and .NET 4.0 Series): http://weblogs.asp.net/scottgu/archive/2010/01/27/extensible-output-caching-with-asp-net-4-vs-2010-and-net-4-0-series.aspx

(3) Introducing the Windows Azure AppFabric Caching Service:
http://msdn.microsoft.com/en-us/magazine/gg983488.aspx

(4) Differences Between Caching On-Premises and in the Cloud:
http://msdn.microsoft.com/en-us/library/gg185678.aspx

Answer 1

As the document you reference indicates there is no way to invalidate a local cache using Windows Azure Shared Caching Service (previously known as Windows Azure AppFabric Caching). This is because that service does not support notifications. If you are not using the local cache option with that service then you can invalidate a cache items by explicitly removing it. That will remove it from the distributed cache in the service and all instances requesting it would then get nothing.

As for replacing the cached page I believe you could do this by updating the cache directly; however, given the number of factors that go into when something is dropped from the cache you may not be able to 100% guarantee that the page wouldn't eventually fall out due to pressure and the race occur anyway.

If you want a lot more control over the cache I'd highly recommend looking at the new Windows Azure Dedicated Caching preview. It's till in preview, so you may not want to risk it with your production work, but it will give you a LOT more control over your cache.