Caching and Database Offloading – Best of both worlds with Terracotta Darwin Release

ashish — Wed, 24 Mar 2010 11:20:41 +0000

Abstract

The Terracotta Darwin release a feature packed release. I love to call it a Developer's delight. Integrating Terracotta with existing apps has been simplified a lot with Express Mode. In this series we shall see some touch upon some of the new features of the Darwin release

How is this post organized?

We shall take a sample Use Case(s), and discuss the needs. Using the Use Case we shall see the fitment of Terracotta features. Discussion will be around the following

Bulk Loading to Cache
Write Behind Cache

The Use Case - Bulk Loading

Bulk loading the cache is a common need for Cache warmup. Here we try to load the data into Cache in a single go, rather then on Cache miss. This help us in reducing the database lookup upon each miss.

Some Use Cases
Case 1: For a Catalogue site, loading all the available catalogues/Products during startup

The cache can be loaded at the startup with the hot set o Products or as desired, against loading it at runtime, upon a Cache miss.

Case 2: For an Element Management System, loading all the Managed Devices into cache, available to all nodes in the cluster

For an EMS Device Information for the Devices it is managing is used most often. The Device info can be bulk loaded at the startup. The example show the use of cache by a Poller, which Polls the Device status.

There are other common use cases. Please add comment with your Use case.

Ehcache Bulk Loading with Terracotta

Terracotta Darwin release has optimized bulk loading in Ehcache. In normal scenario, loading elements in Ehcache, would update the cache entry to all the clustered caches, making the bulk loading a bit slower.

Let's see how bulk loading in action

// Get the Cache to be preloaded Cache ehcache = CacheManager.getInstance().getCache("mycache"); // Set this property before bulk loading ehcache.setNodeCoherence(false); // Load everything here loadCache(); // reset the property ehcache.setNodeCoherence(true); // Wait for all data to be distributed across cluster ehcache.waitUntilClusterCoherent();

What's being done inside the loadCache()?
Here is a glimpse

private void loadCache() { // Query the DB get the data and get the result into array // or what ever data structure you need // iterate over result and put into cache for(int i = 0; i < data.length; i++) { Element element = new Element(data.getId, data); ehcache.put(element); } }

Here is how the cache look when we are bulk loading the data. We are using both nodes to load distinct data to speed up loading process. The loading can be taken care by a single node also.

Once the bulk loading is completed, and Nodes are set to coherent again, the data is replicated across the cluster, and all Nodes have the same data set.

What's Next?
In the next post we shall cover the Write-Behind feature of Ehcache for DB offloading. I will rewrite the code of one my previous post Exploring Terracotta tim-async - Scalable way to off-load DB updates from App Transaction, to use the write-behind feature.

So you want Distributed, Scalable and Highly Available Cache?

ashish — Tue, 09 Feb 2010 09:22:53 +0000

Abstract

So you want Distributed, Scalable and Highly Available Cache? If yes, then this is the right place for you. The Terracotta Ehcache release has these features inbuilt. The Express Installation mode has simplified Terracotta integration in your application.

How this post is organized
First we shall start with simple standalone cache and then see how Terracotta can easily help us create a Distributed, Scalable and Highly Available cache, with a few minor configurations

What all do you need run the example?

Terracotta 3.2.0 - Download it from here

Sample Application
Lets design a sample application (a real simple one), which we shall use to demonstrate the features. Device Monitoring is a common requirement in OSS System, and caching the Device information reduces the Database hits. The essential components of our application are
- DevideInfo - A POJO that stores device information
- CacheHandler - Class that handles cache initialization and other ops

Lets see the CacheHandler class, which is the heart of our implementation

public class DeviceInfo  implements Serializable {

    String deviceId;

    String name;

    // .... other device information

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getDeviceId() {
        return deviceId;
    }

    public void setDeviceId(String deviceId) {
        this.deviceId = deviceId;
    }
}

The class is simple and contains information related to the device.

Let see our CacheHandler class

public class CacheHandler {

    public Cache deviceCache;

    public void initCache() {
        // Initialize the CacheManager
        CacheManager cacheManager = CacheManager.create();
        // Get the Cache to store device information
        deviceCache = cacheManager.getCache("deviceCache");
    }

    public void addToCache(DeviceInfo device) {
        Element el = new Element(device.getDeviceId(), device);
        deviceCache.put(el);
    }

    protected int getDeviceCacheSize() {
        return deviceCache.getSize();
    }

    public static void main(String[] args) {
        CacheHandler handler = new CacheHandler();
        handler.initCache();

        // Lets add 10 devices
        // just to keep life simple
        for(int i = 0; i < 10; i++) {
            DeviceInfo device = new DeviceInfo();
            device.setDeviceId("Device-"+i);
            handler.addToCache(device);
        }

        // Not recommended in production
        System.out.println("Cache Size = "+handler.getDeviceCacheSize());

    }
}

The class has two main functions
- initCache - The API initializes the cache
- addToCache - The API adds the device information to the device cache

Lets see our ehcache.xml

In the configuration we have defined a deviceCache, that we shall use to store device information.

Following is the list of jars you would need to run this app

ehcache-core-1.7.2.jar
slf4j-api-1.5.8.jar
slf4j-jdk14-1.5.8.jar

All these jars are available as part of Terracotta installation under /distributed-cache directory

You can run this example and see the same in action.

Making it Distributed....

Now lets assume that we want to make the Cache fault tolerant, survive JVM crashes, as well as have it available on different JVM's. It should be able to Scale as we add more JVM's to it and other stuff. With Terracotta, we can just do it in a few steps without changing the code. the magic lies with Express Installation mode, introduced in Terracotta version 3.2.0 and above

Lets see the 3 steps that we need to perform

1. Updates to the ehcache.xml
Add following element to ehcache.xml

and for the deviceCache, we add element

here is the updated ehcache.xml

There is no need to change the code

2. Add ehcache-terracotta-1.8.0.jar to the classpath

Lets start the Terracotta Server

3. Goto Terracotta_Install_dir/bin and execute

$ ./start-tc-server.sh

This shall start the Terracotta server

Now run the application on multiple JVM's. The device information is available on all client JVM's

To monitor Cache, you can use Terracotta Dev Console

If you have further question/queries, please visit Terracotta Forums.

What's coming up Next?
The next post shall touch on write-behind feature in the latest Terracotta Darwin release. Its essentially to get best of both worlds - Caching and Database Offloading Stay tuned..

Ashish's Tech Blog » Ehcache

Caching and Database Offloading – Best of both worlds with Terracotta Darwin Release

So you want Distributed, Scalable and Highly Available Cache?