Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Develop a generic caching service to improve performance

Build a timed cache with a background thread

By Jonathan Lurie, JavaWorld.com, 07/20/01

Page 2 of 5

To discern the source of the performance degradation, you use a profiling product and discover that the server loads multiple copies of database ResultSets, each of which has several thousand records. The records make up a product list. Moreover, the product list is identical for every user. The list does not depend on the user, as might have been the case if the product list had resulted from a parameterized query. You quickly decide that one copy of the list could serve all concurrent users, so you cache it.

However, a number of questions arise, which include such complexities as:

• What if the product list changes? How can the cache expire the lists? How will I know how long the product list should remain in the cache before it expires?
• What if two distinct product lists exist, and the two lists change at different intervals? Can I expire each list individually, or must they all have the same shelf life?
• What if the cache is empty and two requesters try the cache at exactly the same time? When they both find it empty, will they create their own lists, and then both try to put their copies into the cache?
• What if items sit in the cache for months without being accessed? Won't they eat up memory?

To address these challenges, you need to construct a software caching service.

In the filing cabinet analogy, people always checked the cabinet first when searching for documents. Your software must implement the same procedure: a request must check the caching service before loading a fresh list from the database. As a software developer, your responsibility is to access the cache before accessing the database. If the product list has already loaded into the cache, then you use the cached list, provided it is not expired. If the product list is not in the cache, then you load it from the database and cache it immediately.

Note: Before proceeding to the caching service's requirements and code, you might want to check out the sidebar below, "Caching Versus Pooling." It explains pooling, a related concept.

Requirements

In keeping with good design principles, I defined a requirements list for the caching service that we will develop in this article:

1. Any Java application can access the caching service.
2. Objects can be placed in the cache.
3. Objects can be extracted from the cache.
4. Cached objects can determine for themselves when they expire, thereby allowing maximum flexibility. Caching services that expire all objects using the same expiration formula fail to provide optimal use of cached objects. This approach is inadequate in large-scale systems since, for example, a product list may change daily, whereas a list of store locations might change only once a month.
5. A background thread that runs under low priority removes expired cached objects.
6. The caching service can be enhanced later through the use of a least-recently used (LRU) or least-frequently used (LFU) purging mechanism.

Implementation

To satisfy Requirement 1, we adopt a 100 percent pure Java environment. By providing public get and set methods in the caching service, we fulfill Requirements 2 and 3 as well.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.