This blog is continuation of our blog on Data caching

Caching with Dependencies

As time passes, the information in your data source may change. If your code uses caching, you may be unaware of the changes and might continue using out-of date information from the cache. To overcome this problem cache dependencies are introduced. They allow a cached item be dependent on another resource so that when that resource changes the cached item is removed automatically.

Three types of dependencies mainly play in caching.

• Dependencies on other cached items
• Dependencies in files or folders
• Dependencies on a Database query

File Dependencies

To use cache dependency, you need to create a cache dependency object, then need to supply that dependency object, while add a new cached item. For example when we create a cache dependency object that depends on an XML file, when the file is changed, the cache dependency will be invalidated and the dependent cached item will be evicted from the cache immediately.

We can also specify a directory that needs to be monitored for changes, or we can supply an array of string that represents multiple files and directories.

Cache Item dependencies

Here we can create a cached item that’s dependent on another item in the cache. Now, when the first cached item changes or is removed from the cache, the second will automatically be dropped from the cache as well.

SQL Server Cache Dependencies

A more complex kind of cache dependency is the SQL Server cache dependency. SQL cache dependencies provide the ability to automatically invalidate a cached data object, when related data is modified in the database.

SQL Cache dependencies still entails more complexity than just using a time based expiration policy. It’s more difficult to set up, and it can be more of a headache to maintain. If it’s acceptable for certain information to be used without reflecting all the most recent changes (and developers often overestimate the importance of up-to-the millisecond live information), you may not need at all.

SQL Server 2005 and 2008 have built in notification infrastructure called “Service Broker”. This manages queues, which are database objects that have the same standing as table, stored procedures, or views.

When using notification with SQL Server, we get following benefits.

• Notification is much finer grained- Instead of invalidating our cached object when the table changes, SQL Server invalidate the cached object only when a row that affects codes query is inserted, updated or deleted.
• It’s more intelligent-A notification message is sent the first time the data is changed but not if the data is changed again (unless we register for notification messages by adding an item back to the cache).
• No special steps are required to set up notification-We just need to call a start service once in our code to enable. There is no other complex coding steps involves.

There are the most important rules to manage notifications. If you break one of these rules, you won’t receive an error. However, the notification message will be sent as soon as you register, and cached item will be invalidated immediately.