Terracotta's open-source release of its clustering solution has the potential to make clustering a deployment-time option for many open-source Java applications. In their interview with Artima, Spring project founder Rod Johnson and Terracotta co-founder Ari Zilka discuss what that means for Spring-based enterprise applications:

http://www.artima.com/lejava/articles/spring_clustering.html

What do you think of Terracotta's approach to clustering?

I'm very curious about this statement by Rod:

----
We are now seeing interest in moving towards a more stateful model. It's at a fairly early stage in the market, but we see considerable interest.

...

Another interesting long-term trend we're seeing is people moving some stuff out of relational databases. A few years ago it seemed that enterprises used a database as a backing store, but what we're actually seeing now, especially in really high-end enterprise environments, is an interest in trying to take some of that functionality out of the database.

Of course, if you do that, you have to solve some of the problems databases do solve. Those problems re-surface in other ways, such as the clustering problems. But you get some very interesting benefits, such as something more object-oriented—you don't have to solve the object-relational impedance mismatch—and you get something that can be many times faster, if done appropriately.

We're seeing situations where people are not necessarily assuming that every piece of data needs to be reliably stored. They don't need to store that kind of data in the database. It may well be that, although some data needs to go into the database, not all working data you would automatically in the past have put in the database needs to be stored there.

There are a range of things that need to have a really permanent record—data for warehousing or auditing, for example. But there is quite a range of things that don't. If you can remove that from automatically going into the database, then you also get a great benefit of simplicity because now you're dealing in pure Java objects.
----

I can see that the reason people may want to move this way is that we now have tools that make it easier to manage distributed state, but I'm very curious what kinds of data are people wanting to move out of the database that they were storing in the database before?

He's probably referring to a number of systems such as those that use Coherence to resiliently manage "live" data (data that is being used and/or modified frequently) in memory. For risk analytics, for example, I visted a bank recently that was able to improve their latency by over 1000x by managing their risk curves and positions in Coherence, making a calculation that used to be impossible to complete in a month using a database into a calculation that could be completed intra-day.

Peace,

Cameron Purdy
http://www.tangosol.com/

I think some of the motivation for moving (some kinds of) data away from databases is to regain control away from the dead hand of database administrators.

My experience is that DAs value stability above everything else. This is fine for data storage and retrieval but is a real bind when it comes to trying to get anything changed.

Hi all,

I just came across this Terracotta article and was hoping a few questions I have could be answered.

Our present product has a proprietary servlet code base. The engineer who put this in place has recently left our company and while I understand some of it, there is little javadoc or info other than bugging him.

We have a product that should it work, it could scale to millions of end users and third parties alike, although naturally that takes time to achieve, so we've got some time for the right solution.

Like others, I am kind of taken aback about the idea of moving back into a stateful setup. Right now we don't use sessions at all, but we basically use a cache and database with a user id and/or email. Because we're small, everything resides in the cache once accessed.

I am curious if moving to Spring, Hibernate, and Terracotta, if the ability to scale is fairly simple yet robust enough to eventually scale to possibly dozens of servers.

One thing I particularly liked about Orion Server back in the day was this notion of cluster islands. You'd basically put three servers in an island, they would session fail over to one another. To scale, you'd add another island of two or three servers. You could add more, but the idea was that not only did most developers back then abuse session objects, thus there was a lot more to replicate across servers in an island, but that keeping each island to about three servers ensured a pretty good failover and scalability combination. If one server out of three died, you still had two failing over, and naturally IT was alerted. More so, you'd throttle each island to use about 60% to 70% so that if one server died, the other two could handle the load. Couple that with a good load balancer and you could easily balance the load to other islands if a server (or two or all three) went down. I recall Orion had their own load balancer software that you could deploy on the client side, or in a separate tier of servers in front of the app servers to properly round robin as well as keep track of load and balance right. With all that said, is there any way to do something similar out of the box with Terracotta, or do you have to keep on adding servers to an ever growing cluster? Maybe there is no need, or advantage to the island approach?

Also, I haven't yet checked, but is Terracotta lgpl or bsd, or is it gpl and thus I couldn't ship it with our app for deployment if we wanted to provide our app to others?

IS there any examples to look at, maybe even use to get up and running, then rework for my app?

Curious how Spring, Hibernate and Terracotta work together. I have yet to play with Spring or Hibernate, so not sure if using Hibernate negates the ability to cluster with Terracotta, or if it's not as good as using strict SQL or what have you?

Given that there is Spring Web Flow and the Spring MVC, which is the ideal solution with Terracotta? Not sure which is the better way to go yet, but I am familiar with MVC and the Web Flow looks a little more than we would need.

I was thinking we'd look to deploy on quad core dual cpu systems, possibly with about 8 to 16GB of memory each. Curious what sort of caching Spring provides that works with Terracotta with clustering as well?

Lastly, sort of off topic, but any of you have experience with 64-bit linux (Fedora, RedHat?) and the 64-bit JVM... to take advantage of the >4GB of memory? Are they rock solid, stable... we'll be deploying on JDK 1.5.

Thank you.

>
> Our present product has a proprietary servlet code base.
> The engineer who put this in place has recently left our
> company and while I understand some of it, there is little
> javadoc or info other than bugging him.

Interesting. You may be able to cluster it with Terracotta directly without significant changes. Terracotta DSO clusters POJOs so if your servlet relies on a cache you can just flag that cache as clustered and see what happens. Might even be zero code changes.

>
> We have a product that should it work, it could scale to
> millions of end users and third parties alike, although
> naturally that takes time to achieve, so we've got some
> time for the right solution.

Kewl.

>
> Like others, I am kind of taken aback about the idea of
> moving back into a stateful setup. Right now we don't use
> sessions at all, but we basically use a cache and database
> with a user id and/or email. Because we're small,
> everything resides in the cache once accessed.

Well, strictly speaking you are correct but if you have a cache, you have a precursor to state. You happen to be able to reconsistute your state across JVMs and restarts. With Terracotta, there is no difference. You flag objects as clustered at runtime and those objects persist across JVM restarts and stay in synch across JVM boundaries. This implies that you get the value of stateless operation (no single JVM is a point of failure) but with a stateful development model (which I believe is simpler...less code for sure).


>
> I am curious if moving to Spring, Hibernate, and
> Terracotta, if the ability to scale is fairly simple yet
> robust enough to eventually scale to possibly dozens of
> servers.

[snip]

> With all that said, is there any way to do something
> similar out of the box with Terracotta, or do you have to
> keep on adding servers to an ever growing cluster? Maybe
> there is no need, or advantage to the island approach?

TC scales by adding servers and not by creating "islands" or "buddies." Several customers have validated our product at dozens (up to about 150) servers. If we cannot scale in a particular use case, one could always go to a multiple-Terracotta-server approach which works much like your "island" example. Many JVMs work together coordinated by a Terracotta server, but you may end up with more than 1 Terracotta server either because too many objects exist or too much data.

>
> Also, I haven't yet checked, but is Terracotta lgpl or
> bsd, or is it gpl and thus I couldn't ship it with our app
> for deployment if we wanted to provide our app to others?
>

We are essentially MPL. I am not a fan of virality. BSD is good but Mozilla is quite permissive as well. With our MPL-style license you can rely on TC to build apps and not pay us a dime. You can also bundle us in software that you burn on CD and sell (or offer up for download) and still not pay a dime. But, if you choose to bundle and not pay us, you have to make it clear to your community that you rely on Terracotta technologies (much like MPL).

> IS there any examples to look at, maybe even use to get up
> and running, then rework for my app?

I would start here: http://www.terracotta.org/confluence/display/orgsite/Tutorials

>
> Curious how Spring, Hibernate and Terracotta work
> together. I have yet to play with Spring or Hibernate, so
> not sure if using Hibernate negates the ability to cluster
> with Terracotta, or if it's not as good as using strict
> SQL or what have you?

We are just on the cusp of getting Hibernate to work. Clustering Spring Beans works fine. Sign up to our mailing lists and check out the archives. There has been lots of discussion in the last 2 weeks on the topic of hibernate integration: http://www.terracotta.org/confluence/display/orgsite/Mailing+Lists

>
> Given that there is Spring Web Flow and the Spring MVC,
> which is the ideal solution with Terracotta? Not sure
> which is the better way to go yet, but I am familiar with
> MVC and the Web Flow looks a little more than we would
> need.

Terracotta works fine with both. Our session clustering product would get you going with clustered Spring Web Flow or MVC. But that product is bundled inside our flagship DSO product. Just download that, IMO. http://www.terracotta.org/confluence/display/orgsite/Download

>
> I was thinking we'd look to deploy on quad core dual cpu
> systems, possibly with about 8 to 16GB of memory each.
> Curious what sort of caching Spring provides that works
> with Terracotta with clustering as well?

Spring doesn't "cache" per se. It relies on the developer to code to design patterns that cache. (This is not entirely true nor is it a dig at Spring but the notion of caching is highly use case dependent.) In general, the marriage of Spring and Terracotta allows you to create Spring Beans that you assume survive restarts and, further, those Beans remain consistent when your app is deployed in a cluster. With Terracotta4Spring, you flag those beans you just coded up as "clustered" and Terracotta takes care of the rest. 1 config entry per bean. It is lightweight for the developer.

>
> Lastly, sort of off topic, but any of you have experience
> with 64-bit linux (Fedora, RedHat?) and the 64-bit JVM...
> to take advantage of the >4GB of memory? Are they rock
> solid, stable... we'll be deploying on JDK 1.5.

We have several clients running 20 - 30 GB JVMs. Only consistent problem I hear is not stability but GC pauses of "minutes."

--Ari