Export (0) Print
Expand All

Design of the Expiration Process

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.

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.

There are four expiration policies provided with the Caching Application Block:

  • Absolute. This means the item expires at a specific time.
  • Sliding. This means the item expires after the specified time has elapsed from when the item was last accessed. The default time is 2 minutes.
  • 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.
  • File dependency. This means the item expires after a specific file is modified.

The first three policies, absolute, sliding, and extended format are referred to as time-based expirations. You should use time-based expiration for volatile cache items, such as those that have regular data refreshes or those that are valid for only a specified time. Time-based expiration lets you 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.

The fourth policy, file dependency, is referred to as a notification-based expiration. It defines the validity of a cached item based on a particular file. If the file is modified, the cached item is invalidated and removed from the cache.

The Add method has two overloads. One assumes the default expiration policy, which is NeverExpired. The other overload lets you set the expiration policies yourself. You can use as many policies as you want, including policies that you create yourself. (For more information about extending the Caching Application Block by adding your own expiration policies, see Adding a New Expiration Policy.) If you have an item with multiple policies, the item will expire if any one of the policy's criteria is met.

Marking and Sweeping

Expiration is a two-part process. The first part is referred to as marking; the second part is referred to as sweeping. The process is divided into separate tasks to avoid any conflicts that can occur if the application is using a cache item that BackgroundScheduler is trying to expire.

During marking, BackgroundScheduler makes a copy of the hash table and examines each cache item in it to see if it can be expired. It locks the item while it is doing this. If an item is eligible for expiration, BackgroundScheduler sets a flag in the cache item.

During sweeping, BackgroundScheduler re-examines each flagged CacheItem to see if it has been accessed since it was flagged. If it has been accessed, the item is kept in the cache. If it has not been accessed, it is expired and removed from the cache. A Windows Management Instrumentation (WMI) event occurs when an item expires.

Callbacks

Optionally, developers can use an overload of the Add method that lets them specify that the application receive a callback after an item expires and is removed from the cache. If necessary, the application can refresh the item.

Items may still be in the cache when an application quits and it is likely that many of those items will have expired when the application restarts. In this case, the items remain in the cache and callbacks for those items occur during the first expiration cycle. However, if an application requests an expired item before the first expiration cycle occurs, the cache performs a callback and returns NULL to the application. This ensures that a callback occurs for every expired item while preventing an application from receiving an item that has expired.

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.
Show:
© 2014 Microsoft