Terracotta Use Cases


Yesterday, I posted a note about what Terracotta has been up to in the last 6 months. Casper Bang commented:

Unlike Ehcache and Hibernate, Terracotta as a magic problem solving layer is somewhat harder to grasp. After having read a bunch of your posts, I am still not 100% sure what Terracotta is or how much is to gain from it. On top of that, an Oracle DBA will claim that Oracle already does the best job at caching.
Have you guys thought of putting together some (simple but concrete) cases for would-be customers to study?

I started answering this in a comment, but I had too much to say. First, on “Terracotta as magic problem solving layer”… At it’s heart, Terracotta is clustered objects and clustered locks using pure Java + external config. You’re absolutely right that that’s pure technology and platform, not a solution to a problem. That technology tends to be useful when you want to stay in your problem domain, assume coherency of your objects with respect to normal Java locking constructs, and get scaling and high availability. We have a bunch of customers that have rolled really amazing solutions to complex problems with those basic tools.

At Terracotta we see our mission as making scaling your Java application simple (*cough* maybe other JVM langs too). We recognize that many people don’t want powerful low-level building blocks. Rather, they have an application that they are trying to scale and when they do there are certain problems that they typically encounter. Our current product line is designed to be a set of drop-in solutions that use the underlying Terracotta technology to address those problem areas.

Currently, the products we are focusing on are:

  • Clustered HTTP sessions – drop-in support for clustering your HTTP sessions on many popular open-source and commercial containers. Generally no code changes required.
  • Clustered cache – take an application using Ehcache and extend that into a cluster, again with no code changes, just some configuration modifications.
  • Clustered Hibernate second level cache – plug in Terracotta for Hibernate as a second level cache provider and get a coherent cache across your cluster. No coding changes – just configure Hibernate and the cache.

Lots of needs fall outside those products. For many of them, we already have custom solutions using Terracotta and we’re happy to help you through those cases as well. We have also identified a handful of pain points that we think are common enough that they deserve their own product, and you might see more showing up in the near future (hint hint).

With regard to “(simple but concrete) cases”, we actually have spent a lot of time on this but I guess there’s always room for more talking about it. About a year ago, we built a reference application called the Examinator, which was an online exam-taking application. It was a good illustration of a few different use cases rolled into a real application (that we perf tested and scaled). Some examples in the context of Examinator:

Exam sessions – this is a canonical example of what we call “conversation” data. It happens all the time in user-facing applications where a user will log on, build up some contextual state over a series of pages, and finally complete the overall work. In this case, the “work” is taking an exam. While the user is taking the exam, they are answering questions, flagging them for later review, etc. All of that data would (in an ordinary web application) get needlessly stored in a database on every page change.

By clustering the exam session information, you still retain the availability of the exam data (any node in the cluster sees a consistent view of it), but without any of the intermediate reads and writes to the database. Instead, you just wait till the end and drop the clustered data back into the database through Hibernate.

Exam test data – the exam sections, questions, choices etc that are available to take are effectively read-only. They can be modified but that’s a rare occurrence. This data is long-lived and stored in the database, and loaded by Hibernate into domain model entities. However, there’s no need to keep hitting the database for it over and over. You really want to load that data once, and cache it forever.

We have used different versions of the exam data cache but the current implementation uses Hibernate second level cache to store the exam data. Because the cache is clustered, only one node needs to load it once and thereafter it is stored in Terracotta-backed Hibernate cache.

User registration codes – as with many web applications, when you register you are sent an email with a registration code so you can confirm your email address. The registration codes are a perfect example of transient data – they need to stick around for a few hours or days, and should be available enough that you don’t have to hit the same server again to verify the code. But you also shouldn’t need to store it in the database at all as it’s purely temporary. Terracotta is a perfect match for that.

Besides these Examinator use cases, another common scenario where Terracotta-backed caches are used is in an inventory use cases. In an inventory use case, you typically have a medium sized data set of items with a fairly hot subset. That hot subset is undergoing a high rate of change. Keeping a cache in sync with a database requires a read/write cache. Having a coherent cache is really important to make sure that you see consistent data between all parties looking at the data (buyers, sellers, etc) as money and contracts are dependent on that data. If you’re looking for what our customers are doing with Terracotta, this list might give you some ideas.

With regard to “an Oracle DBA will claim that Oracle already does the best job at caching”, I don’t think you should take any statement like this as Truth (whether it’s from an Oracle DBA or me). You should build your own test and find out for yourself. There are also many dimensions of “best” – performance, price, maintainability, etc.

Terracotta is open source, free to try, and free to use for many needs. We provide licenses for 24×7 support, indemnification, patch delivery as well as some enterprise level products for extreme scale and better monitoring.


4 Responses to “Terracotta Use Cases”
  1. Ashish says:

    I believe many people get confused with Terracotta coz, it does what none other product can do today. So its kinda niche way of Scaling :-)

    There are couple of more Use Case that I see
    1. Generating unique Id for tables (typically this headache is left to Database). AFAIK, Terracotta makes it pretty easy

    2. DB caching is good, but still we have the overhad of talking to DB, including Network IO, so if we have a cache, we gain a lot. I don’t think there is one on one comparison between a DB cache and Terracotta based cache

    3. Guess Terracotta bases clustered POJO can easily act as Singleton in clustered J2EE environment

    The distributed processing using LinkedBlockingQueue is master piece, processing data across JVM’s was never this simple. I believe Terracotta has much more potential Use Cases, than what I have listed :-)

  2. Tim Vernum says:

    Since tone can be hard to determine in written form, I thought it best to preface this with a bit of context-setter.

    I’m intending this as a piece of advice that is (hopefully) helpful to both of us. Helpful to me because, if you write the article I want, then it will make my life as a product selector a lot easier. And hopefully helpful to you, because if you make it easier for people to know what your product can do for them, then they’re more likely to buy it, and you’re more likely to stay employed :)

    I think Terracotta is a great piece of technology, and I always keep it in the back of my mind as an option for future systems I build, but, like Casper, I’ve never quite got a good handle on what it can do for me.
    As a (mostly former) Jetty developer, I know that it can give me session clustering for Jetty if I ever need that. But that’s about as far as it goes. I suspect the only reason that makes a lot of sense to me is because I know Jetty really well, and I know other servlet containers pretty well, so I know what Jetty+Terracotta adds over Jetty on its own.

    But, that’s as far as it goes for me.

    This blog entry, takes a fairly common approach of starting with the technology, and then expanding that into a use case.
    That’s not surprising – you’re a technologist, and this is your personal blog, so it reflects your mindset.
    But I’m your reader, and in this context, I’m not a technologist, I’m a potential user.
    (Sure, in another context I’m a technologist, but just getting my exciting about the technical merits of Terracotta isn’t going to turn me into a user)

    See, I look at this description and think “so, if I’m already trying to run something across multiple VMs, Terracotta can make some of that work a bit better”. It feels like I have to have walked myself into a bit of a mess (a cluster of VMs without shared data, or a cluster of VMs with an inefficient way of sharing data) before Terracotta has much to offer me.

    But I suspect that’s not the full story. I assume there are problems that I’m trying to solve, where I might previously have used a single VM, where Terracotta would allow me to use a cluster of VMs without all the head-aches. Or maybe I don’t even need to think about it as a cluster, but instead just think about it as “replicated/resilient memory”.

    The stories that would catch my attention would be the ones that start with a problem that needs to be solved. So your user registration codes would start with: “Are you persisting small transient objects to the database just to provide a resilient backing for your data? Terracotta can allow you to keep it all in memory on your VM, while still giving you the resilience you’re looking for.”

    Start with the user – what problem are they trying to solve?
    Then, how can Terracotta be used to solve that in a “better” way than the typical solution people would use?
    That’s the sort of description I’d read and buy into.

  3. Alex says:

    @Tim: Many thanks for your comments and questions. I hope to respond when I have a chance in the next couple days.

  4. Casper Bang says:

    Thanks Alex for answering. Still not sure whether Terracotta would do anything (worth while) for me and my problems, but I guess I’ll have to take it for a spin and give it a chance. :)