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


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

      // Load everything here

      // reset the property

      // Wait for all data to be distributed across cluster

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);

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.

ehcache - While Bulk uploading

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.

ehcache - After Bulk upload

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.

2 thoughts on “Caching and Database Offloading – Best of both worlds with Terracotta Darwin Release

  1. Hi Ashish,

    Thanks for the post.
    If I have two Terracotta clients running and Terracotta client#1 crashes and dies while processing line loadCache(), would my cluster ever become coherent again? In my test case, it seems that the cluster remains incoherent after client#1 dies.
    If that’s the case, it seems that client#2 would just be left hanging at the waitUntilClusterCoherent(). What would be a way around this indefinite wait? Ideally, I would also want client#2 to load whatever that client#1 didn’t complete loading.

    Thanks, Grace

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.