Terracotta for Spring is a runtime for Spring-based applications that provides high-availability and high performance clustering for Spring applications with zero changes to the application code. Terracotta for Spring provides plug-in capacity, availability and scalability for Spring applications with absolutely no changes to existing code. Features:

• 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

It can be downloaded now with registration.

At the terracotta spring site I found this:- "How do you cluster a Spring Application? Historically speaking, clustering an application is not easy. To cluster Spring applications, developers must write a significant amount code and rewrite parts of the application. It also perturbs the domain model and breaks object identity." With Terracotta now available is this statement still true? developers must write a significant amount code and rewrite parts of the application.

With Terracotta Spring, you can declaratively state which bean to cluster (i.e write an XML file similar in style to Spring's config file). It does not intrude onto the domain model - so the application developer has no code to write, in order to get specific beans clustered. Hope that helps.

It also perturbs the domain model and breaks object identity."

With Terracotta now available is this statement still true?
>>To cluster Spring applications,
developers must write a significant amount code and rewrite parts of the application.

You are correct, Neal. This is an error on the Terracotta site and should read "to cluster applications, developers must write..." The point we are trying to make is that Spring makes life easier for messaging, transactions, domain modeling in general. Terracotta helps brings Spring's ability to simplify to the world of clustering. I would say that w/o Terracotta, Spring apps that are clustered are still simple. They are just more stateless than they would be with Terracotta. So, let's call it "simple, stateful, and clustered." Sorry for the confusion. No insult or attempt to mislead intended. Good catch!

So, let's call it "simple, stateful, and clustered."

I'm looking for an alternative for SFSB in spring (statefull, transaction, etc). Can Terracotta solve my problem? If it can, can you give me a simple example or point me to the right place? Thanks, Nathan

I'm looking for an alternative for SFSB in spring (statefull, transaction, etc). Can Terracotta solve my problem? If it can, can you give me a simple example or point me to the right place?

Spring 2.0 introduced scoped beans that are essentially an alternative for SFSB. With Terracotta for Spring you can cluster scoped beans for scopes suported by Spring out of the box. Using clustering features provided by Terracotta for Spring you can transparently cluster your own custom Scope implementation. With the following Spring definitions: Then you can mark customScope bean as clustered and let Terracotta to take care of distributing its data across the cluster. You can also vote for SPR-2065 issue, which should allow to implment even more transparent solution.

I'm looking for an alternative for SFSB in spring (statefull, transaction, etc).
Can Terracotta solve my problem? If it can, can you give me a simple example or point me to the right place?

Spring 2.0 introduced scoped beans that are essentially an alternative for SFSB. With Terracotta for Spring you can cluster scoped beans for scopes suported by Spring

And how is Spring scoped beans + Terracotta a better or SIMPLER alternative to using EJB 3.0 SFSBs?

I'm looking for an alternative for SFSB in spring (statefull, transaction, etc).
Can Terracotta solve my problem? If it can, can you give me a simple example or point me to the right place?

Spring 2.0 introduced scoped beans that are essentially an alternative for SFSB. With Terracotta for Spring you can cluster scoped beans for scopes suported by Spring

And how is Spring scoped beans + Terracotta a better or SIMPLER alternative to using EJB 3.0 SFSBs?

And one more question from me (related to a typical problem in "enterprise" systems): what about declarative / distributed transactions - many (possibly distributed) components transparently sharing the same transactional context?
http://www.enterpriseware.eu

One more question from me (related to a typical problem in "enterprise" systems): what about declarative / distributed transactions - many (possibly distributed) components transparently sharing the same transactional context?

Distributed transactions allow to make certain things really simple to deal with, but this simplicity can be really costly in some cases. In some cases, avoiding distributed transactions could help to improve performance quite a lot. Enterprise systems have many typical problems, and I believe distributed transactions is not the worst one. At least it is somehow addressed by the infrastructure. There are number of other issues, that are practically not covered by the common infrastructure. For instance, process coordination. See an example in my old article about using Spring AOP Framework with EJB components. With Terracotta, coordination of these expensieve requests will be no different from the multi-threaded scenario.

And how is Spring scoped beans + Terracotta a better or SIMPLER alternative to using EJB 3.0 SFSBs?

This obviously depends on what your situation is. If you already have a large investment in Spring infrastructure, then it would probably be simpler to use Terracotta as opposed to converting everything over to EJB 3.0. If your team or shop has been using Spring for awhile and feels comfortable with it, it's probably easier to go with Terracotta instead of learning EJB 3.0. If you're currently using EJB 3.0 and have no experience with Spring, then it'll be easier to use EJB 3.0 SFSBs. If you're starting from scratch with no EJB or Spring experience, then you've got to figure out for yourself what's important to you and weigh those against the tradeoffs of EJB and Spring, or possibly a combination of the two.

And how is Spring scoped beans + Terracotta a better or SIMPLER alternative to using EJB 3.0 SFSBs?

This obviously depends on what your situation is. ...

Obviously. However, this does not address my point. Say you are in a situation where you could adopt both of them, and need only to weigh their respective technological merits to address stateful remoting / remote transaction propagation / security context propagation. How would a combination of Spring and Terracotta be simpler/better than SFSBs for addressing the same problem domain?

I'm looking for an alternative for SFSB in spring (statefull, transaction, etc).

Can Terracotta solve my problem? If it can, can you give me a simple example or point me to the right place?

Thanks,
Nathan

In Terracotta for Spring you can take a regular singleton (Spring) bean and define it as clustered in the TC config. What this means is that it's state will be shared across the cluster, but will still have the same "scope" as before, e.g. it will be scoped to the same "logical" application context. It's regular semantics will also be preserved. In short: you get the semantics and scoping you expect (same as on a single node), but across the cluster. In the upcoming release we will also have support for Session Scoped beans in Spring (new in Spring 2.0), e.g. the scope is bound to the life-cycle of the HttpSession. It will also be completely transparent, all you need to do is to add the true element to the config. (This is actually already implemented and is shipped in the product, but we have decided to wait with officialy support it until Spring 2.0 final comes out, but try it out if you want.) Download the kit and play with it yourself that is the best way of finding out if it is suitable for your specific needs, and if it not, tell us about it and we can try to do something about it. A good demo to start with is the JMX demo in the kit under spring/samples/jmx (read the Readme).

You are correct, Neal. This is an error on the Terracotta site and should read "to cluster applications, developers must write..." The point we are trying to make is that Spring makes life easier for messaging, transactions, domain modeling in general. Terracotta helps brings Spring's ability to simplify to the world of clustering.

How does Terracotta deal with transactions within Spring?

Neal, with Terracotta runtime you can pick Spring-managed beans and mark them as clustered in the Terracotta config. So, your application is still going to run without Terracotta, but when you run it in Terracotta runtime, selected beans will became transparently clustered. There are few demo applications included with the kit you can download from Terracotta web site.

What if my existing application utilizes Hibernate's "increment" identity generator, Terracotta will be able to cluster my objects with no changes? Building scalable, clusterable, reliable applications has more to do with design approach than code. Magically mixing in Terracotta to an existing Spring app that wasn't design to be clustered in the first place is probably not going to be an "out of the box" or "no code" solution. It's cool in that it's basically providing the same functionality that any other app server / container does simply from a "Spring" approach J2EE. I don't know why this hasn't already been done... Cool idea, hopefully a cool product, but the hype is a bit much.

What if my existing application utilizes Hibernate's "increment" identity generator, Terracotta will be able to cluster my objects with no changes?

You would need Terracotta for Hibernate to do that. ;-) On the other hand, if can expose your Hibernate stuff as Spring-managed beans, then you can use Terracotta for Spring to cluster these beans.

Building scalable, clusterable, reliable applications has more to do with design approach than code. Magically mixing in Terracotta to an existing Spring app that wasn't design to be clustered in the first place is probably not going to be an "out of the box" or "no code" solution. t's cool in that it's basically providing the same functionality that any other app server / container does simply from a "Spring" approach J2EE. I don't know why this hasn't already been done...

The message is that application does not have to use any proprietory API and if it is designed to perform well on multithreaded environment, it will perform when clustered by Terracotta.

Building scalable, clusterable, reliable applications has more to do with design approach than code.
Magically mixing in Terracotta to an existing Spring app that wasn't design to be clustered in the first place is probably not going to be an "out of the box" or "no code" solution.
t's cool in that it's basically providing the same functionality that any other app server / container does simply from a "Spring" approach J2EE. I don't know why this hasn't already been done...

The message is that application does not have to use any proprietory API and if it is designed to perform well on multithreaded environment, it will perform when clustered by Terracotta.

Just because an app is designed to run well on a multi-threaded single instance means it has all the necessary characteristics for performant clustering? I still fail to see or agree with this. E.g.1: The Hibernate incrementor mentioned earlier is a specific example, but other app-specific 'cluster-wide singleton' generators of this sort would break. E.g.2: Beans designed from a clean OO model may have a lot of data in it which need not be clustered. Unless such fields are marked as transient or your OO model separates such 'static' fields from dynamic state (both of which point to designing your app with clustering in mind) I don't see how clustering can meet any sort of performance goals. Either that, or you're in XML-hell (one of the downfalls of EJB2, I might add) describing which fields of which beans to cluster when configuring Terracotta.

E.g.1: The Hibernate incrementor mentioned earlier is a specific example, but other app-specific 'cluster-wide singleton' generators of this sort would break.

Why, when you're using it within the Spring context. I don't think there is much difference between the specific example and any other cluster-wide bean.

E.g.2: Beans designed from a clean OO model may have a lot of data in it which need not be clustered. Unless such fields are marked as transient or your OO model separates such 'static' fields from dynamic state (both of which point to designing your app with clustering in mind) I don't see how clustering can meet any sort of performance goals.

Either that, or you're in XML-hell (one of the downfalls of EJB2, I might add) describing which fields of which beans to cluster when configuring Terracotta.

Why don't they need to be clustered? Please explain? That's like clustering your http session object and stating that you want some attributes to not be clustered. Maybe I'm missing your point. Ilya

E.g.1: The Hibernate incrementor mentioned earlier is a specific example, but other app-specific 'cluster-wide singleton' generators of this sort would break.

Why, when you're using it within the Spring context. I don't think there is much difference between the specific example and any other cluster-wide bean.

Well, it was mentioned that when dealing with Hibernate, one should use TC for Hibernate. Is there also a "TC for generic-cluster-wide-singleton"?

E.g.2: Beans designed from a clean OO model may have a lot of data in it which need not be clustered. Unless such fields are marked as transient or your OO model separates such 'static' fields from dynamic state (both of which point to designing your app with clustering in mind) I don't see how clustering can meet any sort of performance goals.

Either that, or you're in XML-hell (one of the downfalls of EJB2, I might add) describing which fields of which beans to cluster when configuring Terracotta.

Why don't they need to be clustered? Please explain? That's like clustering your http session object and stating that you want some attributes to not be clustered. Maybe I'm missing your point.

Imagine a User object, containing stuff like name, address, but also potentially transient stuff like the host he's logged on to. This user object is stored in your http session, but not all of it should be replicated.

E.g.1: The Hibernate incrementor mentioned earlier is a specific example, but other app-specific 'cluster-wide singleton' generators of this sort would break.

Why, when you're using it within the Spring context. I don't think there is much difference between the specific example and any other cluster-wide bean.

Well, it was mentioned that when dealing with Hibernate, one should use TC for Hibernate. Is there also a "TC for generic-cluster-wide-singleton"?

E.g.2: Beans designed from a clean OO model may have a lot of data in it which need not be clustered. Unless such fields are marked as transient or your OO model separates such 'static' fields from dynamic state (both of which point to designing your app with clustering in mind) I don't see how clustering can meet any sort of performance goals.

Either that, or you're in XML-hell (one of the downfalls of EJB2, I might add) describing which fields of which beans to cluster when configuring Terracotta.

Why don't they need to be clustered? Please explain? That's like clustering your http session object and stating that you want some attributes to not be clustered. Maybe I'm missing your point.

Imagine a User object, containing stuff like name, address, but also potentially transient stuff like the host he's logged on to. This user object is stored in your http session, but not all of it should be replicated.

I think you're looking at replication as somehow equivalent to serializing data. When serializing your object graph, there are security issues that are involved and though you want to ensure sensitive info is not persisted, though transient is needed. If you have a clustered app and one session request stores objects in their current state, why wouldn't you want them replicated in the same state? To me, that would make the cluster inconsistent. I'm not arguing that it's not a possibly good addition, maybe by using annotations rather than XML, I just don't see a real life use case there.

I'm not arguing that it's not a possibly good addition, maybe by using annotations rather than XML, I just don't see a real life use case there.

Agreed. I would like to see annotations. We are currently discussing them internally but it is mostly a question of "when", not "if." BTW, our download no longer requires registration, so feel free to give it a shot and get back to us after you have detailed feedback. --Ari

Well, it was mentioned that when dealing with Hibernate, one should use TC for Hibernate.

I was joking. There is no Terracotta for Hibernate. But if there will be enough demand, who knows... :-)

Is there also a "TC for generic-cluster-wide-singleton"?

Actually there is! It is called Terracotta DSO, which is a core product that Terracotta for Spring is based on. Technically you can probably use just DSO, but it is much easier to deal with specific use cases (e.g. Spring-managed components, Hibernate/JPA lifecycle, etc). That is why we created Terracotta for Spring.

Just because an app is designed to run well on a multi-threaded single instance means it has all the necessary characteristics for performant clustering? I still fail to see or agree with this.

Those characteristics can be injected in the runtime. Similarly to how HotSpot JVM does lots optimizations based on information collected at the run time, it is possible to apply the same principles to the clustering needs and inject required QoS into the application.

E.g.1: The Hibernate incrementor mentioned earlier is a specific example, but other app-specific 'cluster-wide singleton' generators of this sort would break.

Not necessary. You would face the same issues if your identity generator is using database as a backend. However there are well known optimizations for this issue and nothing stops you to use these optimizations for your own identity generator. I just wrote a blog entry about that. Anyways, when you know about the nature of your objects (e.g. you know that it is Hibernate id generator) or can provide minimal hints to the runtime (e.g. using annotations, like it can be done for transactional boundaries), these optimizations can be also applied transparently. In reality there is not that many cases require custom tweaking.

E.g.2: Beans designed from a clean OO model may have a lot of data in it which need not be clustered. Unless such fields are marked as transient or your OO model separates such 'static' fields from dynamic state (both of which point to designing your app with clustering in mind) I don't see how clustering can meet any sort of performance goals.

Either that, or you're in XML-hell (one of the downfalls of EJB2, I might add) describing which fields of which beans to cluster when configuring Terracotta.

In real world application, the only small fraction of the app require clustering. If that part is already exposed as Spring-managed components, the only XML you have to add there is list of these bean names. I agree that for some of these beans it will be necessary to mark certain fields as non-clustered. However it is not that bad in the real world case:

• If fields are injected by Spring IoC and came from the other beans defined in Spring config, Terracotta for Spring will automatically mark these fields as non-clustered, unless referenced beans are marked for clustering
• Terracotta can respect "transient" modifier in your Java code, even if your objects aren't serializable
• Fields can be sxplicitly marked as non-clustered in Terracotta config

We also have a prototype for Spring 2.0 where you can use arbitrary metadata/attributes at the bean level in Spring's own XML config to configure clustering. That data is available trough AttributeAccessor and the only issue there that default XML parse only allow to use string values for metadata attributes. I've implemented custom namespace handler for Spring 2.0 that allows to declare more complex structures (i.e. maps and lists). Please vote for Jira issue SPR-1711 if you'd like to see this in the Spring framework.

You would need Terracotta for Hibernate to do that. ;-)

On the other hand, if can expose your Hibernate stuff as Spring-managed beans, then you can use Terracotta for Spring to cluster these beans.

Indeed I can see this as a problem. Imagine that you have a POJO that contains JPA's EntityManager (not just Hibernate!) that has the persistence context. Do you cluster it or not? -Ben Wang

Imagine that you have a POJO that contains JPA's EntityManager (not just Hibernate!) that has the persistence context. Do you cluster it or not?

I am not. :-) But Terracotta for Spring can cluster state and allow process/thread coordination across the entire cluster. On the other hand, what state of EntityManager require clustering in your opinion? Every JPA vendor provides its own cluster-wide caching and you not necessary need Terracotta to do their job. Also, there are many schenarios not related to databases where Terracotta play really nice.

Imagine that you have a POJO that contains JPA's EntityManager (not just Hibernate!) that has the persistence context. Do you cluster it or not?

I am not. :-)

But Terracotta for Spring can cluster state and allow process/thread coordination across the entire cluster.

On the other hand, what state of EntityManager require clustering in your opinion? Every JPA vendor provides its own cluster-wide caching and you not necessary need Terracotta to do their job. Also, there are many schenarios not related to databases where Terracotta play really nice.

EntityManager/Hibernate Sessions can have conversational state in between real JTA transactions. I believe it is called Application Transaction in Hibernate, IIRC. In JPA, its non-transactional access to the persistence context. JPA isn't as clean, nice, or usable as Hibernate's flush mode NEVER (you can blaim Mike Keith's stubborness for that). If you're doing transparent caching, your JPA provider is going to have to handle the case when a persistence context needs replicating. That case because even more complicated when you want to retain object references for managed entities. Bill

What sorts of licenses are available for Terracotta? And what is the ballpark pricing? There is nothing on your website about this. Before spending time looking at something like this I need to know how much it will impact the cost our our product, whether I am talking hundreds of dollars or tens of thousands.

What sorts of licenses are available for Terracotta? And what is the ballpark pricing? There is nothing on your website about this.

Before spending time looking at something like this I need to know how much it will impact the cost our our product, whether I am talking hundreds of dollars or tens of thousands.

TC4Spring is free for 2 JVM's. You could also contact sales AT terracottatech DOT com and they would be happy to provide you either a quote or a copy of our software license language so that you can decide if you are comfortable spending any time on the product. Not to come off as trying to drive you toward the product but if you register you can get the software license as a click-thru like most software out there.

See also: