BT

Terracotta Releases Clustering for Spring

| by Scott Delap Follow 0 Followers on Sep 25, 2006. Estimated reading time: 4 minutes |
Terracotta, Inc. recently released their new Terracotta for Spring product which provides high-availability and high performance clustering to applications written using the Spring framework. Terracotta for Spring integrates at the configuration file level reducing the need for developers to make changes to their code to enable clustering support and eliminating the need to implement Serializable. Among the features and benefits of the new product:

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

Finally we asked Bonér about the larger market. Many clustering products are supplying their own API and providing "Data Grid" support. Bonér replied:

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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.

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.

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

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/

See also by Cameron Purdy

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT