I've been working on a project that has some fairly aggressive performance requirements, and believe me, some of the behavior I've seen with ASP.NET 2.0 caching is a bit odd, especially when you use output caching and cross-page posting at the same time.

In brief, if you use cross-page posts, the destination page uses the cache policy for the original page sometimes. And sometimes not. And sometimes raises an exception. I have discovered why this happens, and can demonstrate it with a three-page demo project (available here.) The bug was reported to Microsoft here.

In general, cross-page posts and caching work as expected. If each page is accessed directly, the cache policy for the page is properly evaluated. If the first page executes a cross-page post to either of the other pages, the cache policy for the destination page is used. Again, this is as expected.

However, if you simply access the PreviousPage property on any destination page, the cache policy for the previous page is used -- not the cache policy for the destination!

If the previous page and destination page both utilize a cache policy that involves varyByCustom, any attempt to access the PreviousPage property will cause an exception (because we attempt to overwrite the cache policy, causing a change to the VaryByCustom value.)

There are several problems here:

  • The cache policy should not be spun up just because I'm checking to see if the previous page is null (frankly this is an argument for Eiffel's command-query separation principle)
  • In fact, I argue that the cache policy should be predictable, and the current situation is certainly not.
  • And the exception just blows chunks.

I'll try to post more about cache wierdness and internals as time permits.