Microsoft patterns & practices: The Enterprise Library

Cache Operations

Instantiating the CacheManager

NOTE : The following namespace must be included.

using Microsoft.Practices.EnterpriseLibrary.Caching;
using Microsoft.Practices.EnterpriseLibrary.Caching.Expirations;

CacheManager cacheManager;
cacheManager = CacheFactory.GetCacheManager("DataCacheManager");

Adding Items to Cache

The following code shows how to use the Add method. Add the code to the method that responds to the request to add an item to the cache.

string id="OrderId";
string name = "OrderName";
int price = 50;
Order order = new Order(id, name, price);
cacheManager.Add(order.id, order, 2, null, new SlidingTime(TimeSpan.FromMinutes(5)));

Note:
Defaults

• Scavenging priority: Normal
• No expiration
• When adding a second item with the same key as an existing item replaces the existing item
• When configured to use a persistent backing store, objects added to the cache must be serializable

Flushing the Cache

The following code shows how to use the Flush method. Add the code to the method that responds to the request to flush the cache.

cacheManager.Flush();

Removing an Item from Cache

The following code shows how to use the Remove method. Add the code to the method that responds to the request to remove an item from the cache.

cacheManager.Remove(order.id);

Retrieving data from Cache

The following code shows how to use the GetData method. Add the code to the method responding to the request to retrieve an item from the cache.

Order order = (Order) cacheManager.GetData(12);

Loading the Cache

There are two methods you can use for loading data:

• Proactive loading. This method retrieves all the required data and caches it for the lifetime of the application.
  • Advantages
    • Application performance improves because cache operations are optimized
    • Application response times also improve because all the data is cached
  • Disadvantages
    • Does not result in most optimized since much of the state is cached even though it may not all be required
    • The Implementation could turn out to be more complex than conventional techniques
      
• Reactive loading. This method retrieves data only when requested by the application and then caches it for future requests.
  • Advantages
    • System resources are not misused.
    • Results in an optimized caching system since requested items are only stored.
  • Disadvantages
    • Performance might decrease when any piece of data is requested the first time because it must be loaded from the source.
    • Checks need to be made every time to ensure the item is in cache

The Expiration Policies

The Caching Application Block's expiration process is performed by the BackgroundScheduler. It periodically examines the CacheItems in the hash table to see if any items have expired. You control how frequently the expiration cycle occurs when you configure an instance of the CacheManager using the Configuration Console.

NOTE : The following namespace must be included

using Microsoft.Practices.EnterpriseLibrary.Caching;
using Microsoft.Practices.EnterpriseLibrary.Caching.Expirations;

Following are the Expiration policies

Time-based expirations

You should use time-based expiration when volatile cache items-such as those that have regular data refreshes or those that are valid for only a set amount of time-are stored in a cache. Time-based expiration enables you to set policies that keep items in the cache only as long as their data remains current. For example, if you are writing an application that tracks currency exchange rates by obtaining the data from a frequently updated Web site, you can cache the currency rates for the time that those rates remain constant on the source Web site. In this situation, you would set an expiration policy that is based on the frequency of the Web site updates-for example, once a day or every 20 minutes.

Time Based Expirations are of three types

• Absolute. Allows you to define the lifetime of an item by specifying the absolute time for an item to expire.
  • Simple-You define the lifetime of an item by setting a specific date and time for the item to expire.
  • Extended-You define the lifetime of an item by specifying expressions such as every minute, every Sunday, expire at 5:15 AM on the 15th of every month, and so on.
• Sliding. Allows you to define the lifetime of an item by specifying the interval between the item being accessed and the policy defining it as expired. This means the item expires after the specified time has elapsed from when the item was last accessed. The default time is 2 minutes

  TimeSpan refreshTime = new TimeSpan(0, 5, 0); // will expire if item has not been accessed for 5 minutes
  SlidingTime expireTime = new SlidingTime(refreshTime);
  cacheManager.Add("Key1", "Cache Item1", CacheItemPriority.Normal,
  null, expireTime);

• Extended format. This allows you to be very detailed about when an item expires. For example, you can specify that an item expire every Saturday night at 10:03 PM, or on the third Tuesday of the month. Extended formats are listed in the ExtendedFormat.cs file.

  ExtendedFormatTime expireTime = new ExtendedFormatTime("0 0 * * 6");
  // expire at midnight every Saturday
  cacheManager.Add("Key1", "Cache Item1", CacheItemPriority.Normal, null, expireTime);

  Extended time format
  
  
  • "<Minute> <Hour> <Day of month> <Month> <Day of week>"
    * means run every period
    Examples
  
  
  • "* * * * *" expires every minute
  • "5 * * * *" expire 5th minute of every hour
  • "* 21 * * *" expire every minute of the 21st hour of every day
  • "31 15 * * *" expire 3:31 PM every day
  • "7 4 * * 6" expire Saturday 4:07 AM
  • "15 21 4 7 *" expire 9:15 PM on 4 July

Notification-based expirations

You can use notification-based expiration to define the validity of a cached item based on the properties of an application resource, such as a file, a folder, or any other type of data source. If a dependency changes, the cached item is invalidated and removed from the cache.

File dependency. This means the item expires after a specific file has been modified.

FileDependency expireNotice = new FileDependency(“Trigger.txt”); // expire if the file Trigger.txt is changed
cacheManager.Add("Key1", "Cache Item1", CacheItemPriority.Normal, null, expireNotice);

NOTE: You can create custom expirations by creating classes that implement ICacheItemExpiration

Configuring Expiration Poll Frequency

The Caching Application Block's expiration process is performed by the BackgroundScheduler. It periodically examines the CacheItems in the hash table to see if any items have expired. You control how frequently the expiration cycle occurs when you configure an instance of the CacheManager using the Configuration Console.

The configuration settings for the Caching Application Block should reflect both an application's caching usage pattern and its system environment, such as the amount of available memory. For example, if an application adds items to the cache at a greater rate than it removes them when scavenging (this is a configurable setting), the cache will continue grow. Over time, this can cause memory starvation. Use the application block's performance counters to help tune the configuration settings for each application.

The following can be configured

• Removal of expired items occurs on a background thread
• You can set the frequency of how often this thread will run looking for expired items
• Count of the cached items to remove during the scavenging process.

One of the four priorities can be assigned to a cached item

• Low
• Normal
• High
• Not Removable.

NOTE: The default value is Normal.

The onus of the items that need to be scavenged is placed on the BackGroundScheduler object. The BackGroundScheduler performs a:

• major sort on priority
• minor sort on LTA

Scavenging is done in one single pass

Expiration is a two-part process

• Marking
  • A copy of the hash table is made. Every CachedItem is checked for expiry. If item is to be expired, it is flagged.
• Sweeping
  • Every flagged item is checked if it has been accessed in the mean time. If accessed it is kept in cache. If not, it is removed.
  • A WMI event is triggered

Extending the Caching Application Block

Typically, to suit one's application needs one can extend and modify the Caching Application Block to accommodate the following

• Add a new Backing Store
  A new backing store can be added by implementing the BaseBackingStore abstract class. The concrete implementation needs to ensure that the backing store remains intact and functional when any operation that accesses the backing store causes any exceptions.
• Add a new Expiration Policy

The following interfaces need to be implemented in case one needs to provide custom expiration policies

• ICacheItemExpiration:
  This interface represents an application-defined rule governing how and when a CacheItem object can expire.
• ICacheRefreshAction:
  This interface refreshes an expired cache item.

NOTE: The implementing class must be serializable.

NOTE: If you want to add new features to the application block, you can do so by modifying the source code (the installer includes both the source code and the binaries)

Instrumenting the Caching Application Block

The Caching Application block also incorporates the following instrumentation:

• Caching Application Block Performance Counters. The Caching Application Blocks records key metrics by writing to the Microsoft Windows operating system performance counters.
  The Caching Application Block includes the following performance counters:
  
  • Total Cache Entries. This performance counter shows the number of entries in the cache.
  • Cache Hits/Sec. This performance counter shows the number of cache hits per second.
  • Cache Misses/Sec. This performance counter shows the number of cache misses per second.
  • Cache Hit Ratio. This performance counter shows the ratio of hits from all cache calls.
  • Cache Total Turnover Rate. This performance counter shows the number of additions and removals to the total cache per second.
• Windows Management Instrumentation (WMI) Events. The Caching Application Block reports significant events within the application blocks by publishing WMI events.

There are several WMI events available to monitor any Cache Related operations

CachingServiceEvent	Is the base event class for all events related to Caching.This base class has a string property named Message that contains the message for the event.
CachingServiceFailureEvent	Is the base event class for all failure events. Includes the following properties:- ExceptionStackTrace (string). The stack trace of the reported exception. ExceptionMessage (string). The detailed message of the exception and the exception stack trace, if this failure is a result of an exception.
CachingServiceCacheFlushedEvent	This event signifies the cache has been flushed
CachingServiceCacheScavengedEvent	This event signifies the cache has been scavenged.
CachingServiceInternalFailureEvent	This event class inherits from the CachingServiceFailureEvent. It signifies that an internal failure has occurred. It includes the string property ConfigurationFilePaththat contains the path of the main configuration file.