Practical ASP.NET

Two Reasons You're Not Using the Cache and How To Deal With Them

Peter stumps for the Cache, despite developers' worries over stale or lost data.

• By Peter Vogel
• 09/24/2008

In an earlier column ("Faster Applications with Caching") I enthused over the wonderfulness of using the Cache. Having been so positive, it's only fair to point out that there are two problems with using the Cache: stale data and lost data.

How Stale Is Your Data?
Developers point out that the data held in the Cache is disconnected from the data in the database and, as a result, is out of date ("stale") as soon as someone makes a change to the database. This is less of a problem then you might think.

For instance, most companies have an enormous amount of data that's non-volatile: It just doesn't change all that often. The obvious example is the list of countries that appears in the drop-down lists on Web pages all over the world. But if you're concerned that a new country may have been added to this list during the day, you can have the items in the Cache dumped every night at midnight. Assuming you're using the code in my previous article, the next time somebody needs that list they'll get the freshest version.

A lot of data is "semi-volatile": It does change, but not very often. Your company may offer a list of services that does change -- but how often? Even if you add a new service, do you need to access it in your Web interface on the same day? If you've arranged for your Cache items to be dumped at midnight, then your application will have the new data tomorrow. This solution also works for data that's updated during batch processes that run at night.

If you do need to have your data refreshed right away, the page or form that updates the list of services can remove the list of services from the Cache after changing it either directly or by calling a Web Service (a simple service that's passed the name of the Cache item to be removed would support all of these requests). If your database engine is SQL Server 2005 or later, you can even automate this process.

Finally, even if your data is volatile, ask yourself, "Is the only application driving the volatility this Web application?" If so, you can write your application to update the data in the Cache rather than the data at the database. Now you're saving time on both your reads and writes.

Losing Data
At this point, it often occurs to people that the Cache is just holding things in memory where things do, occasionally, get lost. In fact, when you start to run out of memory, you're guaranteed that items in the Cache will get lost.

However, there is a solution: the Cache callback. When you insert an item into the Cache, you can specify a method to be called when the Cache discards the item. In the callback method you just need to update the database with the data being discarded. The net result: Periodically, your Cache will be cleared out, your database will be updated with the latest version of the data and (the next time someone needs the data) it'll be retrieved and put back in the Cache.

Updating data in the Cache won't work with a Web farm because each server in the farm will have their own copy of the items in the Cache. However, in that case you can fall back on an earlier solution: When an item changes, remove the item from the Cache on each server in the farm.

At this point, I often hear one last objection: If my Web server crashes, I'll lose all the data in the Cache. I don't have a solution for that problem...but if your Web server is liable to crash, then you have problems that even I can't solve.