4 August 2008
Terracotta
I looked at Terracotta over the last few weeks. My goals were to understand what it does and how it could be helpful to us in the future. To achieve these goals, while evaluating it I always related it back to past projects to look at how terracotta could have been helpful those.
What I found is that it could have helped us in at least 4 different ways.
Session Clustering
The lowest hanging fruit is the ability of terracotta to be used as a session clustering solution. The beauty of it is that it can be done with NO change to the application code. I was able to enable terracotta management of the sessions for our Oyogi application without changing a line of its source code. In fact I did not even recompile it, I only created the terracotta configuration and edited the the JBoss start scripts as described in the Quick Start.
Terracotta can be used in that way for all the major web containers: Tomcat, Jetty, JBoss, BEA WebLogic, IBM WebSphere, Glassfish and Geronimo.
Global Singleton
Terracotta provides the ability to turn traditional (single JVM) singletons into terracotta cluster wide singletons. Those are not “real” singletons as one instance exists on each JVM clustered by terracotta, but they can behave in all manners just like if there was really a single instance shared by all the JVMs. This can also be easily applied to Spring beans thanks to the Terracotta for Spring.
Keep Transient Data Transient
This is where I believe terracotta can have the most unique impact, but it also is where the application structure is directly impacted by the usage of Terracotta. In many applications data that is transient in nature but needs to be shared between JVM instances ends up being stored in the database. Terracotta allows us to keep this data in the Java heap and cluster it. This approach can also in some cases replace the usage of queuing infrastructure (such as JMS) between a producer and a consumer.
Taking full advantage of this requires some changes in the application code, but those changes result in simpler solution. The code is modified to use objects in the heap directly instead of retrieving data from a database (and write to objects in the heap instead of update/insert in a database). A core benefit of this approach is to offload work from the databases and let them do what they are designed to do: store and retrieve persistent data.
Hibernate Second Level Cache
Terracotta provide support for Hibernate from multiple perspectives. First it supports basic Hibernate object clustering: a data object retrieved through hibernate can have it’s lazily read attributes read from any node in the Terracotta cluster. Second it provides clustering of Hibernate detached objects (data objects no kept after the end of the database session). Finally and most importantly it provides support for clustering the use of EHCache as a Hibernate Second Level Cache.
Like the session clustering solution this usage of Terracotta can be completely transparent to the application. An single JVM application should be possible to deploy across multiple JVMs clustered by Terracotta with no changes to the application itself.
Technorati Tags: Terracotta, Hibernate, Scalability, Java, Clustering
tyhgjtygflkhf