Microsoft has introduced a potential timesaver with .NET’s built-in Cache class. In a previous article, I examined the upside of a using the built-in .NET cache and discussed some of the feature’s inherent first generation drawbacks. That was merely an appetizer. Now I’ll expand on my basic sample cache to add the ability to expire items.

Listing A contains the base code.

New and improved
To build a timed cache, we first must create a method for determining if and when an object is going to expire. For the purposes of this article, I’ll assume the user is able to determine the exact expiration date and pass that information to the cache. This code could be enhanced to allow objects placed in the cache to determine their own expiration date.

The insertCachedObject method will be modified to support the expiration of object from the cache. This allows users to provide an expiration date when objects are inserted into the cache. The date parameter is named dtExpiration. The method stores the expiration date passed via the parameter.

.NET offers many ways to store this info. We’ll opt for a relatively simple design that calls for the declaration and creation of a second HashTable that will run parallel to the first. This second HashTable is called htExpiration.

The changes to the insertCacheObject method appear in Listing B.

An alternate approach to storing parameters

Alternatively, we could have created a wrapper object containing a date and object property. If we follow this approach, the insertCachedObject method creates an instance of the wrapper and populates the two properties.

Now we need a way to discover expired items. The lazy and uninspired approach would include checking each cached Object when it is requested through the getCachedObject method. But this approach leaves expired objects in the cache until they are requested, which theoretically might never happen. As long as these expired objects reside in the cache they consume valuable memory and hurt application performance.

Instead of this lazy man’s approach, we’ll rely on a background thread that iterates through the htExpiration HashTable. We’ll create a class called TheReaperThread that has one method to establish an infinite loop. TheReaperThread is declared as an inner class, since it’s used only within the context of the CustomCache object. The code for the entire class appears in Listing C.

Be sure to pay close attention to the Shared Constructor in Listing C, which is responsible for creating a new thread and starting its execution. We’ll now create the test program to ensure the cache is working. The test program (found in Listing D) is created as a console application, although it could be any project created using the .NET framework.

More to come
Our simple timed cache is now complete. It’s functional, but it doesn’t notify users when items expire and it doesn’t allow objects to determine their own expiration algorithms. We’ll take this still simple cache and continue to expand on it in subsequent discussions on Delegates, Memory Management, and other issues.