Terracotta Releases Clustering for Spring

Posted by Scott Delap on Sep 25, 2006

Sections

Development,

Architecture & Design

Topics

Clustering & Caching ,

Java

Tags

Terracotta ,

Spring

Share |

• 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.

1. Back to top

   lazy clustering

   by Alex Popescu

   I am wondering about how reliable is the approach presented in the fragment (and also what is the meaning of "quickly"):
   

   If it [n.b.: a clustered bean] is accessed the system can quickly synchronize changes lazily before providing access to the bean.

   
   
   ./alex
   --
   .w( the_mindstorm )p.

   Reply

2. Back to top

   Re: lazy clustering

   by Jonas Bonér

   I am wondering about how reliable is the approach presented in the fragment (and also what is the meaning of "quickly"):
   

   If it [n.b.: a clustered bean] is accessed the system can quickly synchronize changes lazily before providing access to the bean.

   
   
   Terracotta will make sure that you can not access the clustered bean (or any other clustered instance) until it is fully synched up (you will simply block).
   
   I agree that "quickly synchronize changes" is an odd sentence that can make you wonder. Basically, you will have to pay the price for correctness and coherence some time. Terracotta simply tries to do optimizations that will make sure that you don't have to pay the price unless it is absolutely necessary.

   Reply

3. Back to top

   Re: lazy clustering

   by Jonas Bonér

   I am wondering about how reliable is the approach presented in the fragment (and also what is the meaning of "quickly"):
   

   If it [n.b.: a clustered bean] is accessed the system can quickly synchronize changes lazily before providing access to the bean.

   
   

   
   
   Terracotta will make sure that you can not access the clustered bean (or any other clustered instance) until it is fully synched up (you will simply block).
   
   I agree that "quickly synchronize changes" is an odd sentence that can make you wonder. Basically, you will have to pay the price for correctness and coherence some time. Terracotta simply tries to do optimizations that will make sure that you don't have to pay the price unless it is absolutely necessary.

   Reply

4. Back to top

   Re: lazy clustering

   by Alex Popescu

   Terracotta will make sure that you can not access the clustered bean (or any other
   clustered instance) until it is fully synched up (you will simply block).

   
   
   This makes a lot of sense, as otherwise considering the grid of dependencies will lead to completely weird behavior. Now, I can imagine (or at least pretend :-) ) how this is done when the beans are retrieved or wired directly from the Spring context. But I am wondering if the same synch methods are in place for when the beans are already in use. Also, I am wondering if the same mechanism works when serialization is involved.
   
   

   Basically, you will have to pay the price for correctness and coherence some time.

   
   
   Coherence? :-)
   
   BR,
   
   ./alex
   --
   :Architect of InfoQ.com:
   .w( the_mindstorm )p.
   Co-founder of InfoQ.com

   Reply

5. Back to top

   Data Grid

   by Cameron Purdy

   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.

   
   
   Very interesting to see this discussion is in a category called "Clustering & Caching". We coined the term "Clustered Caching" back in 2001 to try to describe what we had done with our Tangosol Coherence product. At the time, no words really existed to describe this market. Fast forward to today, and there are now a number of companies providing solutions in this general space, including Terracotta.
   
   I do have to disagree a bit with Jonas' assertion above, however. When we talk about "getting" and "setting" some object, we're referring to basic clustered caching functionality. When we talk about a Data Grid, we're referring to the ability to move the data or the operations themselves within a scale-out environment. For example, with a data grid, we can invoke an aggregate calculation against hundreds of millions of objects managed across a grid of hundreds of servers, and the calculation is automatically partitioned and executed in parallel, moving almost no information across the netwok and completing literally hundreds of times faster than if only one server were used.
   
   I don't draw the distinction to detract from the value of clustered caching; the solutions in the clustered caching space are extremely valuable to application developers who do (or may have to) support clustered deployment environments. Just being able to rely on a live, stable "Single System Image" removes most of the big clustering head-aches related to application development.
   
   Peace,
   
   Cameron Purdy
   www.tangosol.com/

   Reply

6. Back to top

   See also

   by Cameron Purdy

   dev2dev.bea.com/pub/a/2006/05/declarative-cachi...
   plainvanilla.typepad.com/spring/2006/05/tangoso...

   Reply

• Older >