Introduction
Data caching is a very important consideration for J2EE applications. Data caching limits the number of remote invocations in distributed applications and improves performance of web applications by reducing the number of calls to the persistent data stores. Even though caching improves performance and makes your architecture work, it can, in fact, complicate design and introduce such complexities as concurrent code and cluster-wide synchronization.
Once it has been decided that data caching is an integral part of the architecture, choosing the right caching solution can prove to be difficult. There is always an option to implement a caching solution from scratch. This approach can have its advantages, but will inevitably affect the project's cost and timeline. Another solution is to choose one of the open-source caching products. When choosing a caching solution, the following questions should be considered:
- Does caching solution provide easy integration with an ORM product?
It should be easy to integrate the caching product with some of the popular ORM products such as Hibernate or Toplink. The domain objects are POJOS map to RDBMS entities and cached in memory, thereby reducing network traffic to the RDBMS.
- Does caching solution provide presentation layer caching?
The cache product should provide HTTP response/JSP caching on the presentation layer.
- Does caching solution allow storage of objects in memory and disk?
In case the memory capacity is full, the cache product should evict objects to a local disk.
- Is it easy to use?
A cache product should expose minimum API for the client to use.
- Does it support distributed cache?
A cache within each JVM needs to be coordinated in a clustered environment.
- Does it allow sharing of objects with a JVM?
All the application threads within a JVM should be able to access the same instance of an object in a cache.
- Is cache invalidation supported?
The caching product should provide a facility to invalidate a cache or a cache group. Cache invalidation should be coordinated in a distributed cache.
- What is the availability level?
The cache maintains a local copy; some operations can continue even if the original source is unavailable.
- Is it scaleable?
In a distributed cache, multiple copies of a cache are available across processes. Thus, the scalability of the server is improved.
- Is it easy to maintain?
The cache product should have proper logging facilities in order to debug the code.
- Does it adherence to standards?
JCache is the standard; in other words, the JSR 107 caching service was born out of the JCP process. If the cache supports the standard, a client can have unified access to the cache.
Available Open-Source Solutions
Against the backdrop of the requirements mentioned above, you will evaluate the various products that cache Java objects. The most important features of the various products are mentioned below.
1. OSCache
1.1 Http Response caching
This feature is useful when dealing with static HTML pages. The Page response can be cached indefinitely in memory thus avoiding reprocessing of the page. OSCache uses the URI and query parameters to form a unique key. This key is used to store page content. HttpResponse caching is implemented as a ServletFilter. Thus, the cache filter abstracts the API usage from the client. The configuration of the cache filter is done in web.xml. By default, the Cache Filter holds the page response in 'Application' scope and refreshes the cache every one hour. These default values can be changed.
1.2 JSP Tag library caching
In case of dynamic pages (JSPs), OSCache provides tags that surround the static part in the page. Thus, only the static part of the page is cached.
1.3 Data Access Layer caching
All ORM tools map RDBMS entities to domain objects. OSCache can be used to cache the domain objects returned by the ORM tool. This drastically reduces the number of network trips to the DBMS server and expense associated with object creation. Most ORM tools have a pluggable architecture for caching; in other words, OSCache can be plugged into any ORM tool. The ORM tool manages the caching of domain objects for the client.
OSCache can be configured for persistence cache. When the memory capacity is reached, objects are evicted from the memory and stored on a hard disk. Objects are evicted from memory based on the configured cache algorithm. However, caution should be exercised when dealing with the hard disk cache.
Out-of-the box OSCache comes with LRU (Least recently used) and FIFO (First In First Out) algorithms. Any of the two algorithms can be configured with OSCache. However, any third-party algorithm can be configured with OSCache.
The cache API is relatively easy to use. An instance of 'GeneralCacheAdministrator' is created and the cache administrator is used to add, update, and flush entries in the cache.
OSCache supports distributed caching. When an application is deployed in a cluster of application servers, the local cache is kept in sync by communication amongst all the caches in the cluster. However, OSCache doesn't provide sophisticated support for state management in a cluster.
OSCache doesn't confirm to the JSR 107 standard.
2. EHCache
2.1 HttpResponse and Page Fragment Caching
EHCache provides 'SimplePageCachingFilter' for caching static pages. SimplePageCachingFilter also gzips the HttpResponse to the browser and the browser unzips the response and shows it to the client. For dynamic pages such as JSPs, EHCache provides 'SimplePageFragmentCachingFilter' to cache the static art in the JSP. However, it doesn't provide any taglib like OSCache for page fragment cache; Page Fragment cache is view agnostic.
2.2 Data Access Layer Caching
EHCache provides a feature to cache domain objects that map to database entities. In fact, EHCache is the default cache for Hibernate. EHCache provides support for memory and disk stores. EHCache provides LRU (Least Recently Used), LFU (Least Frequently Used), FIFO (First In First Out) algorithms out-of-the box algorithms for object eviction from memory. EHCache offers support for distributed caching. The default implementation supports cache discovery via multicast or manual configuration. Updates are delivered either asynchronously or synchronously via custom RMI connections. Additional discovery or delivery schemes can be plugged in by third parties.
The EHCache API is very simple and easy to use.
An important feature of EHCache is that it is JMX enabled. The following can be monitored:
- CacheManager
- Cache
- CacheConfiguration
- CacheStatistics
EHCache offers the most complete implementation of JSR107 JCACHE to date.
Measuring Infrastructure Value
IE 7
Firefox 2.0
