Common Cache Use Scenarios
Common cache use scenarios include an application cache, a second level (L2) cache and a hybrid cache.
An application cache is a cache that an application accesses directly. An application benefits from using a cache by keeping most frequently accessed data in memory .
The following communication diagram illustrates using an application cache:
One of the major use scenarios for a cache is a level-2 (L2) cache . An L2 cache provides caching services to an object-relational mapping (ORM) framework or a data mapping (DM) framework such as Hibernate or iBatis respectively. An L2 cache hides the complexity of the caching logic from an application.
An L2 cache improves performance of an ORM or DM framework by reducing unnecessary trips to the database .
The following communication diagram illustrates using an L2 cache:
The application does not access cache directly in this use scenario. Instead, the application utilizes a high level interface provided by an ORM or a DM framework. The framework uses cache for caching its internal data structures such as mapped objects and database query results. If the cached data is not available, the framework retrieves it from the database and puts it into the cache.
A hybrid cache is a cache that uses an external data source to retrieve data that is not present in the cache. An application using a hybrid cache benefits from simplified programming of cache access.
This use scenario is different from the application or the second-level cache when an application or a data access framework is responsible for populating the cache in case of cache misses.
The following communication diagram illustrates using a hybrid cache:
Caching provides such a great improvement of performance that it is often used without limit. An anti-pattern Cache Them All is characterized by caching all data, without regard to temporal or spatial locality of data access . Cache Them All degrades application performance instead of improving it. The degradation of performance is caused by the overhead of maintaining a cache without benefiting from reduced cost of access to frequently used data.
To avoid the pitfall of the Cache Them All , only data that is hard to get and shows temporal and spatial locality of access should be cached.
Caching Products for Java
While it takes only 10 lines of code to write your own cache for Java, developing a usable cache is a challenging task. The simple 10-line cache is missing many important features required for using it in an application. Some of these features include concurrent access, configuration, eviction to disk and statistics.
Fortunately, several projects have already developed working caching APIs, so there is no need to reinvent the wheel.
A commercial caching API maybe a safe bet if your organization wants to be sure that its requests for help are addressed in time and that a caching API is developed professionally.
Often an organization cannot afford commercial software and is ready to take risks. In such situation a free caching API may be a solution.
The following sections outline some commercial and free product supporting local caching.