The Terracotta Server

At the heart of the Terracotta architecture sits the Terracotta Server. The server's primary job is to replicate state across application servers in the data center, manage connections from various clustered JVMs, and ensure coherence and consistency of application data. In many cases, a single Terracotta server can provide clustering services for all of the Terracotta modules in use in the data center.

DSO Architecture

Terracotta Architecture

The Terracotta Server can operate with a "hot back-up" to meet availability requirements. In the event of a failure in the active Terracotta Server, the back-up automatically takes over transactions from various clustering clients and ensures that the replicated state is maintained. No state information is lost in the application node. Connected clients pause during the failover process. In addition to runtime orchestration of the clustered application, the Terracotta Server provides a natural point for centralized configuration, management, and monitoring of clustering services. Terracotta provides a Management Console that connects to the Terracotta Server and provides metrics about connected clients, contents of object caches, and usage statistics.

Distributed Shared Objects

Terracotta's core technology for clustering JVMs is Distributed Shared Objects (DSO). It works by using bytecode instrumentation of application classes. Essentially, DSO injects hooks into the code as bytecode is loaded in the JVM. These hooks become active at runtime to detect changes to fields on instances of user-targeted classes. Those changes in turn generate messages that are sent to the Terracotta Server to update the replicated state of the object. Likewise, the hooks may receive asynchronous but transactional notifications from the server when state changes are initiated from another instrumented instance somewhere else in the cluster.

The instrumentation process must be configured so that the Java class loader knows which classes to instrument, which instances to replicate, and how to handle concurrent updates of shared objects across the cluster. In the typical case, the configuration can simply indicate that single-JVM concurrency control semantics (as expressed by the "synchronized" Java keyword, for example) should be mapped into the distributed context. The Terracotta Server becomes the lock manager for enforcing concurrency restrictions by communicating with hooks in the shared objects that are woven into the bytecode.