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.
Developers worry that when they use the Cache, they'll be working with stale
data -- or may lose their data altogether. And to that, I say: Stop worrying.
Be happy. Use the Cache.
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
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.
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
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.