ASP.NET 4.0 Cache Extensibility

Stefan SchackowProgram ManagerMicrosoft Corporation

PC41

What's the current state? Why is it changing? How are we changing it?

.NET Framework Caching

A great in-memory object cache in ASP.NET Lots of configurable "knobs"

Expiration policies Automatic scavenging behavior Before and after removal callbacks Extensible cache dependencies

Output caching of ASP.NET content Pages Fragment caching of ASP.NET controls Donut caching with cache substitution Output caching of arbitrary HTTP response

Current Cache Functionality

In-memory cache has various constraints Object cache API exists in System.Web

Awkward to use object cache outside of ASP.NET Common question: Why do I have to include

System.Web.dll in my WPF/Winforms project? Not available in 3.5 SP1 Client SKU

Caching is a "black box" Where can vendors and developers plugin?

Memcached, Velocity, ScaleOut, etc… have no clean integration point available to them

Output caching is completely opaque Each custom caching solution is a completely

different API for developers to learn

Why Make Changes?

Proposed New Cache Functionality

A new, extensible, object cache API in its own namespace and assembly Supports both client and server applications Can be made available on both desktop and

client SKUs A factored version of the ASP.NET cache engine

Extensible ASP.NET output caching Consistent APIs for programming against

Disk-based output caches Custom object caches Cloud-based object caches Distributed object caches

New 4.0 Cache Functionality

Cache

Namespace System.Caching{

}

CacheProvider

Disk based

Windows Azure

Distributed

In-memory

New 4.0 Cache Functionality

Namespace System.Caching{

}

CacheDependency(Sql, Key-based, File)

CacheItem

CacheItemPolicy(expirations,

priority, callbacks)

CacheItem

CacheItem

Cache

Object Caching

demo

New 4.0 Output Cache FunctionalityNamespace System.Web.Caching{

}

Disk based

Windows Azure

Distributed

In-memory

OutputCacheProvider

Default.aspx

Foo.ascx

Output Caching

demo

Core Versus Optional APIs

Cache API is a "union" of common functionality Not all cache providers need

to implement all features Core functionality for all providers

Represented on CacheProvider base type Storing and retrieving a key-value pair Basic Add/Get/Set/Contains/Remove methods Named cache partitions

Providers specialize by deriving from InMemoryCacheProvider OutOfProcessCacheProvider

InMemoryCacheProvider

Represents a provider running exclusively in a single app-domain Count of items in cache Sliding expirations

Distributed caches usually can't synchronize sliding expiration values across multiple servers

Cache dependencies (derivations of CacheDependency) Distributed caches may have

no concept of dependencies Item removal callbacks (before and after

removal) Distributed caches may not be able

to call back to anything

OutOfProcessCacheProvider

Represents a provider that stores data outside of an app-domain Version-based updates (CacheItem.Version)

Useful for caches that support optimistic concurrency

Lock-based updates (CacheItem.LockHandle) If a cache supports pessimistic concurrency

Get multiple items Saves multiple round-trips on fetches

Query-tag metadata (CacheItem.QueryTags) Retrieving multiple cache items based on string tags

"Velocity" Integration

"Velocity" – codename for distributed cache created by the Sql Server team

Planned "Velocity" integration points OutOfProcessCacheProvider implementation

for object caching SessionStateStoreProviderBase implementation

for ASP.NET session state Sidenote: Updates to session state API are planned

in 4.0 to allow for more granular sets and gets. OutputCacheProvider implementation for

ASP.NET output caching

Checking cache capabilities

demo

Migrating From Existing APIs

System.Web.Caching.Cache Current plan is that it stays un-changed Might enable "opting-in" to using an object

cache provider Requires developing a “shim” that can re-route calls

to the new object cache provider layer Currently the “shim” is only in the “idea phase”

ASP.NET output caching Both page and control caching can opt-in to

using custom providers By default both types of output caching

continue to use ASP.NET’s in-memory cache

Migrating From Existing APIs

ASP.NET control output caching<@OutputCache outputCacheProvider="…" />

ASP.NET page output caching Programmatically choose different providers Override a new method on HttpApplication

HttpApplication.GetOutputCacheProviderName

Custom page output caching supports: Absolute expirations File-based dependencies only Validation and substitution callbacks

must be static

Migrating From Existing APIs

System.Caching System.Web.Caching

Cache Cache

CacheDependency CacheDependency

SqlCacheDependency SqlCacheDependency

FileCacheDependency constructor parameter

CacheKeyCacheDependency constructor parameter

CacheItem.Key method parameter

CacheItem.Value method parameter

CacheItem.CacheItemPolicy various method parameters

CacheProvider & derivations hard-coded in-memory support only

Summary

4.0 Caching is all about extensibility! Both object caching and ASP.NET output

caching will be pluggable New object cache APIs available for both

client and full versions of .NET Framework

Breakout Sessions/Chalk Talks PC21 – ASP.NET MVC PC30 – ASP.NET Dynamic Data PC31 – ASP.NET and Jquery PC32 – ASP.NET Ajax Futures PC33 – Microsoft Visual Studio:

Easing ASP.NET WebDev PC41 – ASP.NET Cache Extensibility TL48 – Microsoft Visual Studio:

Web Development Futures ES15 – Deploying Web Applications with Microsoft

Internet Information Services 7.0 and the Web Deployment Tool

Related Content

Evals & Recordings

Please fill

out your

evaluation for

this session at:

This session will be available as a recording at:

www.microsoftpdc.com

Please use the microphones provided

Q&A

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market

conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.