Caching Solutions in Java, Page 4
6.2 Data Access layer caching
As mentioned above, SwarmCache supports caching of domain objects in this layer.
There is no mention of SwarmCache getting plugged into any of the popular ORM tools. Hence, it is assumed that caching in the data access layer needs to be done specifically using SwarmCache's API.
SwarmCache supports the LRU caching algorithm. However, SwarmCache is essentially an in-memory cache. When LRU is set as the caching algorithm and the memory capacity is reached, SwarmCache evicts the memory objects as per LRU logic from its memory.
SwarmCache uses soft references to the cached objects. So, if the LRU is not set as the caching algorithm, it relies on the garbage collector to swipe through its memory and clean objects that are least frequently accessed. However, SwarmCache recommends a combination of the above two to be set as the caching algorithm.
It provides API for clearing local cache.
7. Java Caching System (JCS)
- JCS is a cache that supports caching data in memory, or a disk on a remote server using RMI. JCS is more suitable for caching data on the Data Access layer.
- JCS doesn't support caching of HttpResponse and Page Fragment caching on the presentation layer.
- JCS supports distributed cache. All updates and invalidations to the local cache are broadcast to all the caches involved in the cluster. Hence, it can be inferred that JCS is more suitable for applications that have frequent reads and infrequent updates.
- The JCS cache area can be in memory, indexed disk space, remote cache, and lateral cache. A combination of caches also can be configured. If the area in memory is full, objects are evicted to disk.
- In JCS, the data in the disk is indexed to facilitate easy retrieval from disk. A remote cache is more suitable when you have multiple web server JVMs running on the same node.
- The configurations of JCS are set in a properties file named config.ccf file.
- JCS provides API for accessing its cache from a Java class.
- Cache4j is a cache for Java objects that stores objects only in memory. It is mainly useful for caching POJO objects on the data access layer.
- It supports LRU (Least Recently Used), LFU (Least Frequently Used), and FIFO (First In First Out) caching algorithms. For storing objects in its cache, cache4j offers hard and soft references. Cache4j is implemented in a way that multiple application threads can access the cache simultaneously.
- Cache4j provides easy to use programming APIs.
JBoss offers two kinds of cache flavors, namely 'TreeCache' and 'PojoCache'. Look at each of the two models in detail.
JBoss Tree Cache is a cache to store POJO (Plain Old Java Objects). However, every object stored in the cache has to be a serialized java object; in other words, the object has to implement the java.io.serializable interface in a distributed tree cache. The cache is structured as tree—each node in the tree is a map.
The tree cache can be local or distributed.
If a change is done to a field in a POJO, the tree cache serializes the entire POJO. This can be expensive if the object size is a huge one.
JBoss Tree cache offers caching in memory. If the memory reaches a limit, objects are passivated to a disk.
Tree cache is JMX-enabled; it can provide statistics regarding the Cache to a MBeans server.
It provides hooks for client code to attach listeners when a cache event occurs.
Tree cache is transactional in nature. So, any updates/invalidations to an object in the cache are replicated to all the trees in the cache only after the transaction successfully commits. In case the transaction fails, no communication happens amongst the tree caches.
JBoss Tree cache can be plugged into any of the popular Application Servers: IBM WebSphere, Bea Weblogic, Hibernate ORM tool, and so forth. It can be used in a standalone Java application that isn't run in the context of an Application server.
Note: JBoss Tree cache is more for caching domain objects and doesn't support HttpResponse caching and Fragment caching in the case of a dynamic page like a JSP.
9.2 POJO cache
At the outset, POJO cache differs from TreeCache in that the objects in the cache needn't implement the java.io.Serializable interface.
POJO cache supports fine grained replications; only the changes made to the POJO are serialized. Also, any changes to the object are replicated across the cluster automatically; there needn't be any API call to do this action.
POJO cache too supports object eviction to a disk. If the memory gets full, the objects are passed to a disk.
POJO cache is transactional in nature and supports a distributed cache.
As in Tree Cache, the POJO cache tool is more for storing domain objects on the data access layer.
POJO cache can be used in the context of an Application Server and in a standalone java application too.