During the past 18 months, a rapidly growing number of organizations have been taking advantage of the emerging JCache standard for distributed caching to help scale application performance while at the same time reducing infrastructure costs.
This article looks at some of the strengths and weaknesses of various caching architectures, examines how they fit into the surrounding J2EE and other ecosystems, and pinpoints each one's "sweet spot." It will look at both "flat" and multi-tier frameworks, and contrast standards-based frameworks with proprietary offerings.
JCache: A Pluggable Java Temporary Caching Framework
The JCache specification (see sidebar) standardizes in-process caching of Java objects, and removes from the application programmer the burden of implementing standard cache features such as data validation, locking, eviction, and management (see Figure 1). As well as providing the basic put and get methods (a Cache extends a standard Map), the API offers a pluggable CacheLoader interface so users can add custom loaders for whatever data sources they are using.
An increasing number of products are supporting the JCache API; of course, simply supporting JCache is only a part of the solution. Depending on the problem you and your application developers are trying to solve, you should carefully consider which cache architecture best fits your requirements and constraints.
What Are the Trade-Offs Involved in Caching?
Caching is always based on compromise; a trade-off between performance, scalability, and accuracy using the various resources available. Ease of configuration is an important secondary consideration. Let's consider how we balance these factors to achieve the best performance possible.
Accuracy - How Stale Is Your Data?
When reading data from a cache for the second and subsequent times, how do you know whether the data is "stale"? Has the underlying data been changed? A cache can make one of the following assumptions:
Neither of these approaches is perfect - either can leave a wide-open window of vulnerability during which stale data could be used by the application. We'll see later how active, pushed-based caches can reduce or remove that window.
Scalability - Will the Cache Itself Become a Bottleneck?
Although a cache is intended to improve performance, simplistic techniques can sometimes have a counterintuitive effect. If you try to cache too much data, or if data is aged out too frequently, then the cache can add more overhead than it saves. Does your cache expand to such an extent that it is using up all your physical memory? If so, you may be spending far more time and effort paging (thrashing!) your virtual memory than you saved on data access.
