I would love to make an AppFabric provider. I actually really need it :)
However I seriously doubt this is an hour or two kind of hack. here is why (I am not an expert btw):
- First of all I strongly recommend making the provider based on ASP.net Caching and then use the App Fabric cache provider for Asp.net. this will make our work reusable with other cache providers like memcache. either way I assume that AppFabric caching
will only allow me to add objects by key and setting an expiration date on them
- If I want to invalidate an item on AppFabric cache using any mean other than time based, I would have to call "Remove" on that object's key. Orchard on the other hand invalidates cache items when IsCurrent of a cache token returns false this is done even
for time based expiration (see IClock). this leaves me with two problems:
- How to evict items using Signals? (the current implementation maintains a dictionary of signal keys and tokens and sets IsCurrent to false when a signal is triggered. to replicate this on a distributed environment there needs to be an association with signal
keys and cache keys so that we can call "Remove" on a cache key when a signal is triggered that should evict it. the solution that we come up with should take into consideration that an azure instance can create a signal (calling ISignals.When) and another
completely different instance could invalidate it (calling ISignals.Trigger)
- How to evict items using Time? the current implementation of IClock will have to be swapped into something that would pass the expiration time somehow to AppFabric caching.
I have also found some usage of caching that primarily assumes that Orchard is running on one Machine like in MonitorExtensions in DefaultOrchardHost the ShellContext is disposed when a cache item by the key "OrchardHost_Extensions" is invalidated. this
means that only one instance of Azure will feel this change and dispose its shell while other instances would simply find the item in cache and not call DisposeShellContext.
I have also found (though not sure I understand it correctly please correct me if I am wrong) that orchard scopes cache by Type. Meaning that items stored in cache by class A will not be found in cache by class B. I came into this conclusion by looking at
DefaultCacheManager.GetCache which sends the type of the class using the current instance of DefaultCacheManager (class A or B passed to it by CacheModule.AttachToComponentRegistration) to the ICacheHolder which uses it to construct a key to get the ICache
which is used to get cached items. Is this correct?