Dependency Inversion using Terracotta

I am not an expert in enterprise applications caching in the Java EE space. However it does not take an expert to appreciate the non-invasive clustering and caching solutions offered by Terracotta's Virtualization Server. Enjoy!

Traditional caching solutions based on api s run as services within the JVM and implemented using a clustered hashmap that has to be replicated within all participating JVMs. The developers use get methods to fetch data from the cache and put methods to update cache. Terracotta does it the other way - their implementation of virtualization server inverts the relationship between the application server and the cache. The cache is no longer inside the server; rather, the server is now running inside a DSO-enabled JVM. Instead of developers accessing the cache state, Terracotta manages identity of all cached objects as Java references in its virtualization server. When the client issues a "set" on his POJO, Terracotta DSO intercepts the call using bytecode instrumentation, and automatically distributes the change to the other replicas in the cluster. Neat stuff!

What value does this Terracotta caching architecture bring to the world of Java EE applications ?


Apart from all the architectural benefits that the apiless paradigm presents, I think the killer proposition is their offering of "drop in clustering" without "any" application code change. At a time when enterprise level Java EE applications are scaling out with hundreds of CPUs, Terracotta's combination of Virtualization Server and DSO-enabled JVMs provide the right value. Complex enterprise applications built incrementally over layered frameworks can now run within a scalable multi-level clustering infrastructure with capability to share object states across JVMs.

Is the Terracotta architecture scalable in the mass market ?


We have interesting observations from some of the lead architects. Billy Newport, of Websphere group in IBM, feels that the success and scalability of the apiless architecture of Terracotta caching depends a lot on the developer's ability to churn out correct multi-threading code, which he feels is a real tough ask. He expresses his concern that

It's hard to write multi-threading code that scales vertically. ... Why do we think customers can now write perfect multi-threading code that can be transparently distributed using a non invasive approach?

Cameron Purdy of Tangosol (who also offer clustered caching solution through Coherence), is vehemently against Terracotta's bytecode instrumentation based approach, which he feels "will simply re-invent the same fundamental mistakes that JBoss AOP Cache and Gemstone/J already discovered". Working with simple POJO references that preserve object identities is being viewed by him as an attempt to build a fully transparent OODBMS in Java, which will fail in the context of the current JVM design. Follow him more in the Comments section of this page.