Bahar Limaye

Caching information on the WebLogic tier can significantly increase performance and reduce the number of external system calls needed for data retrieval. This is especially true when an application wants to store bits of information that rarely change, such as a list of countries or catalog entries. Nowadays, memory is so cheap that application architectures can benefit from caching data on the Web/EJB tiers.

This is not a new concept; most developers already do this. Whether it's accessing data from a simple java.util.Hashtable or java.util.Hashmap, or using a sophisticated LRU cache mechanism (a derivative of LinkedList), there is minimal overhead in accessing information. The real question isn't how the data is cached or what mechanism is used for storage, but how to preserve the data's integrity and notify cluster members of changes in a highly available, clustered environment.

For example, suppose you're building an e-commerce storefront application that sells clothing. The product information such as the item name, description, SKU, price, and image can be stored in memory on the application tier. The benefit of storing the data in memory is faster page loading and a reduction in database calls.

Now, what happens when your business user wants to change the price or description of the catalog item? How would you notify all of the members of the cluster of this "delta" change? Remember, you probably still want the data to be stored in memory if possible for performance reasons. Also, you probably want the information to be updated in close real-time and don't want to reload all of the data if it hasn't changed.

This article illustrates a simple technique for implementing a "lazily reconstructable" cache system that notifies cluster members of invalidations (deletes).

For example, look at the following code:

static Hashtable cache = new Hashtable();

public Product getProduct(String productID) {
Product product = (Product) cache.get(productID);
if (product == null) {
  // get the product from the database
  product = ProductDAO.getProduct(productID);
  cache.put(productID, product);
}
return product;
}

A simple java.util.Hashtable stores the list of products indexed by the product identifier in a static cache. Products are retrieved from the database and added to the cache lazily if they don't already exist. This code snippet demonstrates how to retrieve a product by looking into cache and grabbing it if it doesn't exist.

What happens if a product description changes for a specific product? Look at this code:

public void changeDescription(String productID, String newDescription)
		throws ProductNotFoundException {

 	ProductDAO.changeDescription(productID, newDescription);

	Command command = new InvalidateCacheCommand(productID);
        ClusterNotifier.notify(command);
}

The code behind the ProductDAO.changeDescription method updates the product ID in the database with the new description. The ClusterNotifier.notify method (see Listing 2) will delete the product from the local cache and send an invalidation event to the cluster members to delete the product from its local cache. Once this is done, all of the members in the cluster will have the product removed from memory. If a user requests this product on any node, it becomes lazily initialized with the new description that was set. See the snippet below from getProduct() example:

if (product == null) {
  // get the product from the database
  product = ProductDAO.getProduct(productID);
  cache.put(productID, product);
}

This will reinitialize the product from the database and insert the information back into cache.

How does this work? Well, let's take a look.

Deep Dive into the Classes
Note: This article uses unpublished private APIs from WebLogic. They work with WebLogic 7.x and 8.x, but there's no guarantee they'll be supported in future versions. Many of the underlying details were "introspected" by putting the WebLogic.jar in the classpath of the IDE.

Command Interface (Generic)
First, let's take a look at the Command interface. It's simple. It defines a single method called "execute."

public interface Command extends Serializable {
	public void execute();
}

The Command interface is used to do the work that needs to be done in the cluster. Notice that it is Serializable. It contains the logic to do a task when it reaches each cluster member. This interface is generic enough to do any operation. This article discusses how this interface can be used to invalidate keys in a cache across the cluster.

InvalidateCacheCommand Concrete Implementation (Specific)
The class in Listing 1 is a concrete implementation of the Command interface to invalidate the keys in a cache. Notice that the execute method clears the entry of a statically bound cache. How does this work?