This post originated from an RSS feed registered with .NET Buzz by Scott Watermasysk. Original Post: Whidbey Caching 2.0 Feed Title: ScottW's ASP.NET WebLog Feed URL: /error.aspx?aspxerrorpath=/blog/rss.aspx Feed Description: ASP.NET and Blogging Latest .NET Buzz Posts Latest .NET Buzz Posts by Scott Watermasysk Latest Posts From ScottW's ASP.NET WebLog

I learned lots of good stuff during the summer, but decided to pop into Rob's caching talk yesterday and picked up a couple of other interesting tidbits (get the slides here and the code here):

Most people have already heard about the SqlCacheDependency. Here is the general break down of it:

• SqlCacheDependency is supported in Sql Server 7, Sql Server 2000, and Yukon.
• Version's 7 and 2000 will require some sql setup (all sql, no "code" install
• Version 7 and 2000 out of the box will only support table level changes. You can of course alter the sql to fit your own needs. (it is possible MS will release some sample code to help you)
• Yukon will support row level changes out of the box
• Version 7 and 2000 will use a poll on a background thread for changes
• Yukon will use a push method

In addition, in Whidbey Cache 2.0, CacheDependency is no longer a sealed class and looks to be quite easy to create your own dependencies (timed, Oracle, etc)

A couple of other interesting additions to the Cache API is the ability to edit part of the output cache (Post-Substition) and a new callback that will fire before and item is removed from the cache.

At the end of the night, I also popped into Steve Smith's caching BOF. I had the chance to finally ask Rob if there was a compeling reason to reference the cache view Context.Cache instead of HttpRuntime.Cache. While only one cache instance will exist per AppDomain, Rob said there is a perf penalty for accessing the cache via HttpRuntime.Cache (similar penalty for using HttpContext.Current when it could instead be passed in as local variable). See my sample cache here.