New Caching Features in ASP.NET 2.0

The four main new features are:

1.)SQL Cache Invalidation
2.)Post-Cache Substitution
3.)Fragment Caching API
4.)Cache Configuration

SQL Cache Invalidation:

Let us assume you've got a web page which queries data from a database. If this is data that doesn't change very often, then there's really no need to query the database for the data each time a user requests the web page, so we decide to cache the data. The problem then becomes, how long do we cache the data for? If we cache it for too short a period then we make our web server work harder then it needs to. In the larger scheme of things, this will increase our operating costs since the server won't be able to handle as many requests and we'll need to add another server sooner then we really should. If, on the other hand, we cache the data for too long a period then we risk users being presented with out of data information. How big a problem this is really depends on the actual application and the data being cached, but it's generally not good to be showing users out of data information.

So finding the optimal length of time for which to cache a certain piece of data is not an easy task. It depends on a lot of factors. Some of those include -- how quickly the application needs to respond to users, the amount of users it needs to support, how frequently the data in the database changes, how quickly those changes must be reflected in the web pages, and what are the potential consequences of displaying old data?

What if instead of us having to continually check to see if there have been any changes, we could simply ask the database to tell us when there's been a change made. This is where SQL cache invalidation comes in. Instead of just picking a length of time to cache our data for, with ASP.NET 2.0's SQL cache notification we can set it up so that when the data is changed in the database, the cached version of the data is automatically cleared.

Post-Cache Substitution

Post-cache substitution is for that situation where most everything on a page can be cached except for one or two little exceptions that must be handled dynamically. In ASP.NET 1.x, the only way to handle this type of scenario was to split the page up into sections that could be cached and then make those into user controls. It worked, but it could be really confusing because you had to sort of reverse your thinking about the problem. It was no longer "let's cache everything but this one little section", but instead became "let's find everything we need to cache and turn it into a user control so we can cache it." All of a sudden your page is split up into ten different user controls and everything got complicated simply because we wanted to do something like put a current timestamp at the bottom of the page.
Post-cache substitution is exactly what it says it is. We take something that has been already been cached and simply substitute some dynamic data back into it. In effect, we are caching the whole page and then just executing the one little part that we didn't cache.
There are two ways to implement post-cache substitution. You can either use the Response.WriteSubstitution command or the control.

Fragment Caching API

The method used most often to cache sections of a page is called fragment caching. Fragment caching is what I described earlier where you move the sections to be cached into user controls and then set the OutputCache directive at the top of the control to cache it. This works fine in all versions of ASP.NET, but in ASP.NET 2.0, we now have access to the fragment caching API. This means that we are no longer stuck just choosing a finite number of minutes to cache the control. Now we can programmatically adjust the caching options.

Cache Configuration

There have been two main advances in this area: the ability to create and use cache profiles and to set cache properties via your application's configuration files.

Cache Profiles :
In ASP.NET 1.x you needed to set the length of time for which a file should be cached via the OutputCache directive at the top of the file. This made changing caching configuration relatively difficult because in order to change the setting you had to modify the setting in each file which implemented caching.
In ASP.NET 2.0, you can define what are called cache profiles. This allows you to create named sets of settings which are defined in your web.config file. Then if you find you need to make a change to one of the profiles, all you need to do is edit the profile in the config file and the change is picked up by all the scripts using that profile.

Cache Configuration via Config Files :
You can now modify caching parameters via ASP.NET's configuration files . You can enable or disable output and fragment caching, modify a number of parameters and even specify how much memory the system should allow caching to use.