When Does Asp.Net Remove Expired Cache Items?

Question

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:

1. Simply mark the item as expired, then execute the CacheItemRemovedCallback on the next access attempt?

2. 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?

Answer 1

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.