- Terracotta is pretty slick.
- It is easy to learn/work with.
- It could be leveraged to provide clustering fairly easily.
- It has great tools & integrations
- You still have to think to write effective distributed code.
- There are some gaps you have to fill.
Terracotta is a relatively easy way to cluster java applications. It uses a server (or server array) to manage client JVM instances as a single, clustered java virtual machine. The implications of that are fairly large. It means that memory is shared across the cluster, including the objects in that memory, and that failure of one VM doesn't shut down the application. A list of features is
- Clustered VM
- Shared memory
- Fine-grained shared-object state propagation
- Shared-object locking & transactions using thread locking semantics
- Virtual heap/Garbage Collector - Transparent data management from local in-memory to remote in-memory to disk
- Fail-over safety via multi-nodes, disk persistence
It should be noted that most of the above is handled in a very transparent manner. It is either handled for you, or is easily configurable. For instance, locking & transactions are handled through bytecode injection into objects you declare to be shared. Here is an example:
synchronized (someObject) {
someObject.data = "test";
}
In uninstrumented java, the above code obtains a lock on someObject, changes its data member variable to the value "test", and then releases its lock. If this is a managed object in Terracotta, the above code obtains a cluster-wide lock on someObject, changes its data member variable to the value "test" in the local VM only, then releases the cluster-wide lock. At this point, the change to the data member variable is published to the cluster. All other nodes with a reference to someObject will have its state changed automatically. Also of note is that this is a fine-grained operation. Only the value of the data field is propagated across the cluster, not the full serialization of someObject.
So whats the catch? Well, there are some clustering almost-necessities that apparently are not provided. At least, I haven't seen them. If anyone reads this and knows different, please correct me. I would include in this list:
- Operational splitting (map/reduce)
- Load balancing
- Message routing
- Sub-clustering
So I would say Terracotta is very strong in clustered data management, but short on operational clustering. Interestingly, I would reverse that statement when describing GridGain, another java clustering technology alternative. I'm actually looking at how feasible it is to integrate both to leverage their strengths together. I'll post more about GridGain and this experiment later.
Check out Terracotta for yourself: http://www.terracotta.org/
Check out GridGain for yourself: http://www.gridgain.com/
