Features

• Generation of a terracotta configuration file
• Generation of terracotta enabled start up scripts for containers

Installation
grails install-plugin terracotta

Usage
Install the plugin
Run the start up script generation task
Run the terracotta configuration generation task
generate a war for the application and deploy in a container
start the terracotta server(s)
start the application servers

Components
Generate<ContainerName>Script: Generate the start up script for an application server
GenerateTcConfig: Generate the tc-config.xml file for terracotta

Generate<ContainerName>Script
Currently only 2 containers are supported: jboss and tomcat.

Edit TerracottaConfig.properties to set the parameters for the start up scripts:
The terracotta install directory on the target jboss or tomcat server:
terracotta.install.dir
The path place where the tc.config.xml will be made available to on the servers (this plugin does not remote copy it you have to do that):
terracotta.config.path

Run:
grails generate-jboss-scripts

Copy the generated scripts in the startup script folders of the containers. You will later start the containers using these scripts instead of standard ones.

GenerateTcConfig
Generates the tc-config.xml required to run a terracotta enabled container.
It enables the clustering of all the domain classes defined in the project and allows to add any additional classes to be made clusterable by including a user defined xml segment.
It also clusters the http sessions across the container instances for your application.

Edit TerracottaConfig.properties to set the host names and ports for the terracotta servers to be used by the application.

Edit CustomIncludes.xml to specify any additional terracotta include rules required by your application.

Run:
grails generate-tc-config

Copy the generated file on each container server, in the location specified when generating the container start up scripts.

Running the Clustered Application
Deploy your application on all the container instances.
Start the terracotta server(s)
Start the containers using the generated start up scripts. (Note that you will need a form of load balancing to witness the effects of the clustering, I used Apache with mod_jk)

Fun Note
Start one only one node of your cluster. Start a session (log in your app, …). Stop that server instance, then start another one. Continue using your application without losing your session!

Looking Ahead
Future enhancements include support for more containers (easy), and support for running terracotta in development mode (more complex).

Technorati Tags: Terracotta, Grails, Scalability, Java, Clustering

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