When you add an item to the System.Web.Caching.Cache
with an absolute expiration date, as in the following example, how does Asp.Net behave? Does it:
Simply mark the item as expired, then execute the CacheItemRemovedCallback
on the next access attempt?
Remove the item from the cache and execute the CacheItemRemovedCallback
immediately?
HttpRuntime.Cache.Insert(key,
new object(),
null,
DateTime.Now.AddSeconds(seconds),
Cache.NoSlidingExpiration,
CacheItemPriority.NotRemovable,
OnCacheRemove);
MSDN appears to indicate that it happens immediately. For example, the "Expiration" section of the "ASP.NET Caching Overview" says "ASP.NET automatically removes items from the cache when they expire." Similarly, the example from the topic "How to: Notify an Application When an Item Is Removed from the Cache" says "If more than 15 seconds elapses between calls to GetReport
[a method in the example], ASP.NET removes the report from the cache."
Still, neither of these is unambiguous. They don't say "the callback is executed immediately" and I could conceive of how their writers might have thought option 1 above counts as 'removing' an item. So I did a quick and dirty test, and lo, it appears to be executing immediately - I get regular sixty-second callbacks even when no one is accessing my site.
Nonetheless, my test was quick and dirty, and in the comments to my answer to Is there a way to run a process every day in a .Net web application without writing a windows service or SQL server jobs, someone has suggested that Asp.Net actually defers removal and execution of the callback until something tries to access the cache again.
Can anyone settle this authoritatively or is this just considered an implementation detail?
Hurray for Reflector!
Expired cache items are actually removed (and callbacks called) when either:
1) Something tries to access the cache item.
2) The ExpiresBucket.FlushExpiredItems
method runs and gets to item. This method is hard-coded to execute every 20 seconds (the accepted answer to the StackOverflow question Changing frequency of ASP.NET cache item expiration corroborates my read of this code via Reflector). However, this has needs additional qualification (for which read on).
Asp.Net maintains one cache for each CPU on the server (I'm not sure if it these represent logical or physical CPUs); each of these maintains a CacheExpires
instance that has a corresponding Timer
that calls its FlushExpiredItems
method every twenty seconds.
This method iterates over another collection of 'buckets' of cache expiration data (an array of ExpiresBucket
instances) serially, calling each bucket's FlushExpiredItems
method in turn.
This method (ExpiresBucket.FlushExpiredItems
) first iterates all the cache items in the bucket and if an item is expired, marks it expired. Then (I'm grossly simplifying here) it iterates the items it has marked expired and removes them, executing the CacheItemRemovedCallback
(actually, it calls CacheSingle.Remove
, which calls CacheInternal.DoRemove
, then CacheSingle.UpdateCache
, then CacheEntry.Close
, which actually calls the callback).
All of that happens serially, so there's a chance something could block the entire process and hold things up (and push the cache item's expiration back from its specified expiration time).
However, at this temporal resolution, with a minimum expiration interval of twenty seconds, the only part of the process that could block for a significant length of time is the execution of the CacheItemRemovedCallbacks
. Any one of these could conceivably block a given Timer
's FlushExpiredItems
thread indefinitely. (Though twenty seconds later, the Timer
would spawn another FlushExpiredItems
thread.)
To summarize, Asp.Net does not guarantee that it will execute callbacks at the specified time, but it will do so under some conditions. As long as the expiration intervals are more than twenty seconds apart, and as long as the cache doesn't have to execute time-consuming CacheItemRemovedCallbacks
(globally - any callbacks could potentially interfere with any others), it can execute expiration callbacks on schedule. That will be good enough for some applications, but fall short for others.
Expired items aren't immediately removed from the cache, they're just marked as expired. You don't get a callback until a cache miss. I ran into this back in the ASP.NET 1.1 days, and it hasn't changed.
There may be cases where expired items are removed immediately - such as if there's low memory and high CPU - but you can't count on it.
I usually use a timer that reloads the cache on a regular basis.