views:

817

answers:

2

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?

+1  A: 

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.

Jon Galloway
I like the technique you substitute for cache expirations in your article! But I'm still skeptical: my test site has been running all day, unattended with virtually nothing else running on my machine, dutifully hitting its callback every minute. Why do you say that they are only marked as expired? Is it because of the Steve Smith article you link to? (http://msdn.microsoft.com/en-us/library/aa478965.aspx) He only *asserts* that expired cached items are not removed - and ...
Jeff Sternal
... it's a little unclear about whether he's talking about particular cache expirations or just the one he uses (the NoAbsoluteExpiration / TimeSpan.Zero configuration). Please let me add too that I don't mean to be disrespectful to Steve (or you!), who has contributed mightily to the .NET community at large. It jsut contradicts what I see with my own eyes (and I'm certain my tests aren't vitiated by high memory / cpu usage). I guess I need to download Reflector and see for myself, and which point I'll gladly update this and eat some well-deserved crow. :)
Jeff Sternal
I'd love to be proven wrong! I haven't seen callbacks happen reliably in .NET 1.1, 2.0, or 3.5. Do you have something that's pinging the site keeping the site alive? Can you give more specifics on your code and hosting?
Jon Galloway
Howdy Jon, sure thing - I certainly appreciate the input, since this is mighty vexing! I'm just running it on my development box right now, with a vanilla XP SP2 installation, IIS 6.0. I compiled to the 2.0 runtime, set up a virtual, and accessed the page once. The only thing my logs show is Cruise Control hitting my ccnet server every 5 minutes. The code is basically exactly like the example from http://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/. In the CacheItemRemoved method, I'm writing a message to the Windows EventLog.
Jeff Sternal
+7  A: 

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.

Jeff Sternal
Excellent, thanks for digging into this. I'm pretty sure this has improved since I dug through it in Reflector several years ago. Also, ASP.NET 4 includes additional enhancements for caching, some of which are listed here: http://www.asp.net/learn/whitepapers/aspnet40/
Jon Galloway
My pleasure - it turned out to be pretty interesting. Of course, now that you've brought it up, I have to spend part of my weekend looking at the latest 4.0 beta assemblies, blast you! ;)
Jeff Sternal