I currently cache the result of a method invocation.
The caching code follows the standard pattern: it uses the item in the cache if it exists, otherwise it calculates the result, caching it for future calls before returning it.
I would like to shield client code from cache misses (e.g. when the item has ex开发者_JS百科pired).
I am thinking of spawning a thread to wait for the lifetime of the cached object, to then run a supplied function to repopulate the cache when (or just before) the existing item expires.
Can anyone share any experience related to this? Does this sound like a sensible approach?
I'm using .NET 4.0.
Since this is ASP.NET, the Cache.Insert()
method allows you to specify a callback delegate.
Does this sound like a sensible approach?
Yes, the callback (and File-dependency) are supplied for exactly this kind of situation. You still have ro make a trade of between resources, latency and out-of-dateness.
A new addition to the .NET Framework 4.0 is the MemoryCache Class
Quote from the Docs:
The MemoryCache class is similar to the ASP.NET Cache class. The MemoryCache class has many properties and methods for accessing the cache that will be familiar to you if you have used the ASP.NET Cache class
You could use the AddOrGetExisting Method to get or create a CacheItem if does not exist.
Here's a cache that never expires anything:
var cache = new ConcurrentDictionary<TKey, TValue>();
var value = cache.GetOrAdd(someKey, key => MyMethod(key));
Does that help?
Here's a cache that never expires anything and refreshes the value after a certain lifetime:
var cache = new ConcurrentDictionary<TKey, Tuple<TValue, DateTime>>();
var value = cache.AddOrUpdate(someKey,
key => Tuple.Create(MyMethod(key), DateTime.Now),
(key, value) => (value.Item2 + lifetime < DateTime.Now)
? Tuple.Create(MyMethod(key), DateTime.Now)
: value)
.Item1;
Does that help?
There doesn't seem to be any point in expiring an object just to immediately recreate it. Just turn off expiration; dtb shows how.
精彩评论