Distributed Cache

Every application requires some level of caching, either its finite value (values which remain same for the application) cache or cache which holds stateful objects like HTTP Session objects. If the application is running in the same JVM, there is no problem*(don’t miss the *) but then we have a single point of failure.

Problems in caching: I would rather say important decisions which are mostly taken wrong.
1. What data to cache - should business entities / transactional data be cached?
2. How to clear the cache? Should soft references be used? How to remove the cached items which are not used?

So, running the same application in a clustered environment makes the above decision making process even harder.

There are different solutions to solve the above problem like JCache which takes care of distributing and synchronizing the objects in cache. Now a new project Infinispan [JBoss] expose the same interface as JCache [JSR-107] but takes a one step further to provide highly available data grid platform. So, what’s the difference? The difference is how data is being cached. In a typical caching systems the data is just replicated to provide high availability & therefore total memory available remains the same even after running the application in cluster [If we replicate the same object @ N servers, we need N * sizeOf(Object) memory in heap.] On the other hand data grid solutions increase the total effective heap size by replicating the objects in any given K servers [ K < N & K > 0]. So, what does it mean? It means that I can choose which objects I want to replicate in the cloud and how many times.

According to me data grid solutions make more sence. If you read the project introduction of Infinispan carefully, JBoss is going to concentrate on it and stop supporting JCache soon.

The purpose of this post is to lay down the background of what I will be blogging about in the coming few post. In the next post, we'll talk about J2EE Clustering, associated issues and its solutions.