JVM level Clustering Solution (Open Terracota)

What is it?

To make applications scalable and highly available we need to run java application on more then one JVM. This is known as JVM clustering. JVM-level clustering enables applications to be deployed on multiple JVMs, yet interact with each other as if they were running on the same JVM. Open Terracotta allows threads in a cluster of JVMs to interact with each other across JVM boundaries using the same build-in JVM facilities extended to have a cluster-wide meaning

What does it provide?

It provides transparent clustering and coordination services for the Java platform by allowing us to selectively share object graphs across the cluster (Heap level Replication), manage heaps much bigger than for a single JVM (Large Virtual Heap) and distributed wait/notify and synchronized capability (Cluster wide locking semantics). All this with no serialization.

What all we can do with it?

HTTP Session Replication, Distributed Cache, Work/Manager Distributed Queries, POJO Clustering – Everything from Spring Beans to java.util.HashMap etc etc

How does it work?

Uses a client-server architecture where the JVMs running the clustered app connect to a central Terracotta server at startup. The server stores the object data and coordinates thread concurrency between JVMs. The Terracotta DSO libraries inside the application JVM handle the bytecode instrumentation at class load time. It transfers the object data and the lock/unlock requests at synchronization boundaries between the app JVM and the server at runtime. Terracotta uses Aspects to weave byte code instrumentation into the clustered objects at runtime. The bytecode of a class is intercepted at load time and examined by the Terracota transparent libraries.

Declarative Clustering – Roots and clustered object graphs.

Using a declarative approach, object graphs, declared as a Root and all the objects reachable from the top level become clustered objects. It is declared in the Terracotta configuration with a unique name. When a non-clustered object is referenced from a clustered object, the new object and the entire graph becomes clustered. Once a object becomes clustered it is assigned a cluster-wide unique id and remains clustered for its lifetime.

Fine grained change replication

The transactions that contain changes to object contain only the data of the field that has changed. These transactions are sent to the server and also to the other clustered JVMs (if they have those objects instantiated on the heap) to keep the cluster consistent

Object Identity and Serialization

Terracota does not use serialization to replicate object changes. It ships the object id which has changes, the field id and the bytes for the changes value instead of the whole serialized object graphs. Apart from efficiency it preserves object identity – only one instance of a clustered object on the heap at the given time. Any changes made to a clustered object are available to every other object that has reference to the changes object.

HTTP Session Replication

Sessions should be available across application servers to avoid losing it in case of an application server failure. Terracotta session replication allows access to any active session from any application server irrespective of where it was created. Scales well because only that data which has changes is sent and it is sent only when needed.
Can make changes to an object graph and these changes will available through out the cluster without calling setAttribute() on the session. Works with all Struts, Spring web flow, wickets etc.

POJO and Spring clustering

Terracotta provides clustered spring beans. We just need to define which application context and which beans in that context we need cluster. Terracotta clusters those beans and the application context events transparently and with the same semantics across the cluster as on a single JVM.

Distributed cache

Clustered object graphs make naturally good distributed cache. If we need to load the data of a catalogue, we can just do it once for all application servers i.e. for a cluster. Application servers do not have to dump and reload parts of the cache due to memory constraints. Maintaining clustered object consistency and cache coherency across a cluster is as simple and as easy to understand as basic data structures.