JBossCache Overview

How to use JBossCache >>

JBossCache: JBoss Cache is a replicated and transactional  cache that can be used to store Java Objects. JBoss Cache is a fully featured distributed cache framework that can be used in any application server environment and standalone.

Today's large-scale enterprise applications, where scalability and high performance are required in-memory caching has a lead role to play. An in-memory cache can store either application state information or database query results. As many enterprise applications run in clustered environments, cache needs to be replicated across the cluster. Further, if greater reliability is needed, the cache should also be persisted to the hard disk or database.

JBoss Cache provides a powerful and easy to use system for caching frequently accessed data. JBoss Cache eliminates the time-consuming process of accessing the database for each request.

Types of JBossCache: There are two flavor of JBossCache

1. JBoss Core Cache(fks - Tree Cache)
2. JBoss Pogo Cache(fks - Tree CacheAOP)

Tree Cache: Tree Cache is a tree structured replicated transactional cache, that can be used to replicate data transactionally across multiple processes. So if we add an element to one tree, it will appear in all the trees in the cluster. A cache can either be local or replicated. 

Replication can be either asynchronous or synchronous. A synchronous replication blocks the caller until all trees in a cluster have been updated where as the synchronous replication simply puts the modification(s) on the bus and returns immediately, with replication going on in the background. JBossCache can be used transactionally, meaning that if you have a transaction, JBossCache will collect all modifications and only replicate at the end of the transaction. 

We can configure the JBoss cache though a configuration xml file or we can set it programmatically through it’s get/set methods.

Tree CacheAOP: TreeCacheAop extends the functionality of TreeCache but behaves as a true object cache providing transparent and finer-grained object mapping into internal cache. TreeCacheAop is a subclass of TreeCache, that uses instrumentation of class code to know when the state of an object has been changed. This helps to track changes to objects in the TreeCacheAop, and only replicate the changes at the end of a transaction. So if we have a big object and if we want to make some small changes in the object, so far we would have had to serialize the entire object and send it across the wire, wasting bandwidth and CPU cycles for serialization. In the TreeCache AOP case since we track changes to this object, only the changes will be replicated. So this will give us good performance, and not because AOP is so fast, but because we can reduce serialization and unnecessary network traffic.

Tree Cache Basics: The structure of a TreeCache is a tree with nodes. Each node has a name and zero or more children. A node can only have 1 parent. A node can be reached by navigating from the root recursively through children, until the requested node is found. It can also be accessed by giving a fully qualified name (FQN), which consists of the concatenation of all node names from the root to the node.

A TreeCache can have multiple roots, allowing for a number of different trees to be present in a single cache instance. Note that a one level tree is essentially a HashMap. Each node in the tree has a map of keys and values. For a replicated cache, all keys and values have to be Serializable.

A TreeCache can be either local or replicated. Local trees exist only inside the Java VM in which they are created, whereas replicated trees propagate any changes to all other replicated trees in the same cluster. A cluster may span different hosts on a network or just different JVMs on a single host.

The first version of TreeCache was essentially a single HashMap that replicated. However, the decision was taken to go with a tree structured cache because 

(a) it is more flexible and efficient and 

(b) a tree can always be reduced to a map, thereby offering both possibilities. The efficiency argument was driven by concerns over replication overhead, and was that a value itself can be a rather sophisticated object, with aggregation pointing to other objects, or an object containing many fields. A small change in the object would therefore trigger the entire object (possibly the transitive closure over the object graph) to be serialized and propagated to the other nodes in the cluster. With a tree, only the modified nodes in the tree need to be serialized and propagated. This is not necessarily a concern for TreeCache, but is a vital requirement for PojoCache (as we will see in the separate PojoCache documentation).

Structure of a Tree Cache: