Object Caching in a Clustered Environment

Any J2EE application needs some type of caching. Whether, the application needs to cache some meta data or some global objects , caching has always been used. Caching can dramatically improve performance of your application. The idea behind caching is to store locally any data that changes infrequently but which may be nonetheless expensive to obtain from the data source—such as data obtained from a database.

Most of applications I have come across or even developed myself, make use of some type of Singleton pattern making use of a hash table. Here we create a singleton object which gets the data from the database and caches.

public class GlobalCache
{
private static GlobalCache
instance = null;
private List classes;

public static GlobalCache getInstance() {
If (instance == null) {
instance = new GlobalCache ();
}
return instance;

}

// Prevent instantiation

private GlobalCache () {
classes = loadDataFromDB();
}

public List getClasses() {
return classes;
}
...
}

This approach works fine for standalone applications, but for a distributed environment, this approach won't work because the caches on individual nodes must get synchronized within the cluster.
Now, what are the options available to us?

One way is use caching solutions available in the market. Products like

SwarmCache
OSCache
EHCache

This is just a sample, market is flooded with caching solutions.

But, in case we do not want to use any of these caching solutions and want to develop something in-house that supports caching across clustering.. (Typical mindset of controlling what's happening in the application ?)

In a clustered environment each server runs in its own JVM, which poses an interesting problem: What happens when the repository changes on one node in the cluster? The caches residing in the other application server nodes quickly become out of date, and users connected to other servers in the cluster will get stale data.

The option is to make use of JMS. JMS is a natural fit for this problem, and it has the following advantages:

• JMS provides a simple yet flexible messaging API
  
• JMS is standard in any J2EE compliant application server
  
• MS is the basis of EJB 2.0's Message Driven Beans (MDB), which greatly simplify writing asynchronous J2EE applications

I am currently working in developing a caching solution on the same lines. Once finished, I will share my findings.