OpenTerracotta is a Java VM clustering solution that was recently open-sourced. (For an in-depth Artima interview with Terracotta founder Ari Zilka, and Rod Johnson, founder of the Spring project, see Spring Clustering with Terracotta.)

One of the promises of OpenTerracotta is that it enables clustering objects across multiple JVMs without a developer having to change an application's source code. Instead, clustering occurs entirely via configuration options. A recent article by Orion Letiz, Introduction to OpenTerracotta goes into some of the details of such "transparent clustering."

Letiz gives a general overview of OpenTerracotta's architecture:

OpenTerracotta allows threads in a cluster of JVMs to interact with each other across JVM boundaries using ... JVM facilities extended to have a cluster-wide meaning. These clustering capabilities are injected into the bytecode of the application classes at runtime, so there is no need to code to a special clustering API...

Clustering behavior is injected into an application by instrumenting the bytecode of the application classes as they are loaded into the JVM. Terracotta uses bytecode injection techniques similar to those found in many Aspect-Oriented Programming frameworks such as AspectJ and AspectWerkz...

The bytecode of a class is intercepted at load time and examined by the Terracotta transparency libraries. The bytecode is then modified according to the configuration before being passed on to the JVM to be blessed as a class.

The purpose of the bytecode instrumentation is to allow VM-level bytecode operations to extend across multiple cluster nodes, coordinated by a central server:

[Open]Terracotta uses a hub-and-spoke architecture where the JVMs running the clustered application connect to a central Terracotta server at startup. The Terracotta server stores object data and coordinates thread concurrency between JVMs...

The [Open]Terracotta DSO [distributed shared object] libraries inside the application JVMs handle the bytecode instrumentation at class load time and transfers object data and the lock and unlock requests at synchronization boundaries, as well as the wait(), and notify() requests between the application JVM and the Terracotta server at runtime.

To maintain object changes, the PUTFIELD and GETFIELD bytecode instructions are overloaded. PUTFIELD instructions are trapped to record changes to a clustered object's fields. GETFIELD bytecode instructions are trapped to retrieve object data from the server as needed, if it hasn't already retrieved the object referenced by the field in question from the server and instantiated it on the heap.

Letiz also discusses how thread-level bytecode operations, such as object locking, is extended across multiple JVMs. Letiz then provides practical examples in session clustering and POJO clustering with OpenTerracotta, illustrating the sort of configuration files required to affect the bytecode instrumentation.

What do you think of OpenTerracotta's approach of enabling bytecode operations with cluster-wide meaning?