Terracotta Releases Clustering for Spring

• High performance runtime for Spring Applications
  
• Cluster Spring Beans, Events, JMX State and Spring WebFlows
  
• Virtual memory for large, shared Java heaps
  
• Flexible sharing and locking configurable at runtime
  
• Cross-JVM Thread coordination (Wait / Notify)
  
• Runtime visibility into the application cluster
  
• Distributed shared data without database load or abuse
  
• Works with existing Spring applications
  

InfoQ sat down with Terracotta Sr. Software Engineer, Jonas Bonér, to discuss the new product. In regards to what Terracotta for Spring brings to the table versus the existing Terracotta DSO product Bonér responded:

Terracotta for Spring adds another level of clustering Java by allowing declarative, configuration based clustering. It allows you work on Spring component and service level in addition to the JVM level support of Terracotta DSO. Terracotta for Spring minimizes the configuration needed by the user by figuring out as much as possible at runtime. For example Terracotta for Spring tries to find all the classes that needs to be prepared for clustering and where the necessary locking is needed, by inspecting all the classes that are reachable from the clustered component. It also allows you to exclude references to sockets and file handles and other resources that aren't clusterable. Terracotta for Spring also clusters Spring WebFlow, the Spring event system, as well as session scoped beans.

We then asked Bonér about JMX support:

Spring allows developers to expose the state of their beans through JMX. Comparatively we allow developers to expose the same information when a bean is clustered. If you can expose that state on one JVM you can expose it clustered. Basically we guarantee that the application has the same functionality and semantics when clustered as when running on a single JVM.

One question that developers have been asking in regards to Terracotta for Spring is does it support clustered transactions. Specifically they are curious about XA compliance and rollbacks. Bonér commented:

Support for JEE TX (JTA/XA etc)  is being seriously considered.  At the moment we act just like the JVM acts. We are simply extending the regular semantics of Java. We are working (generically) at the VM level, below (and unaware) of any XA-enabled or other JEE deployed app. As a result XA TXs does not impact DSO and vice versa.

You have 3 different situations.

1. The client crashes before a DSO TX is even started: Nothing to do.

2. The client crashes right *after* a DSO TX has been started, but has *not* been committed yet (in the middle of a DSO TX): We rollback the changes and when the client comes back the initial (old) state is paged in.

3. The client crashes right *after* a DSO TX has been *committed*: All changes are propagated throughout the cluster, and when the client comes back the new state is paged in.

We have the same semantics as a synchronized(obj) {...} block on a single VM. Pessimistic locking with no need for rollback. If we were to do anything else we would not act like a single node VM (e.g. not correct/not transparent).

We are looking at solving developer problems first by simplifying the programming model. In data grid solutions developers must first retrieve a bean from the grid in order to modify it. They must then set it back into the grid to propagate the changes. Maintaining these relational maps between the objects perturbs the domain model by forcing you to layer some sort of primary-foreign-key relationships on top of your domain model. This forces Java developers to start thinking like relational database designers, something that is very unnatural to most developers. They simply want to be able to change a bean and the system worries about the rest. We preserve common Java programming characteristics such as pass-by-reference and garbage collection across the cluster. However, nothing prevents you from building data grid style applications based on Terracotta DSO. Taking a step back, by solving the core developer problem first, to allow for simplicity and a single programming model (plain Java), more and more applications will be able to leverage "Data Grid"-like architectures without the increased complexity.

Bonér went on to comment that Terracotta clustering capability can act in a lazy fashion on sending delta's of changes to other nodes when an object is accessed on the heap. If a clustered bean is never accessed on a specific node the overhead of synchronizing its changes is not incurred. If it is accessed the system can quickly synchronize changes lazily before providing access to the bean.