« Since when did the 'P' in POJO come to stand for "Pretend" | Main | FUD OF THE WEEK »
July 18, 2007
Why should I look at Terracotta? Because bean-style gets tiresome
posted by ari
I saw an email to our sales team today that made me very happy. The gist is that a customer is using Terracotta not just because it saves them money but because it makes their application "more elegant" and they like the code they are writing in conjunction with Terracotta.
For those who don't know, Terracotta is a plug-in to your JVM to help share objects and thread state across JVMs without extra code or programming models. It makes enterprise programming lighter weight.
Bean-style programming seems to be the alternative. In most alternatives to Terracotta, be they JMS, JGroups, DAOs, EJB2, or custom clustering solutions, there is some sort of get() / put() abstraction where serialization might even get called and magically copy appropriate object graphs around a bunch of JVMs.
Terracotta is quite different from bean-style programming. As an aside for those who are wondering why they should listen to a vendor like me, we are open source so you don't have to pay Terracotta to get these benefits. What's more, the license is Mozilla-based which means you can do anything you want with it (no restriction on number of JVMs, size of dataset, and you can edit the source if you really want to) but you cannot redistribute it. As for technical differences, they fall along 3 dimensions: faster, simpler, more reliable apps result from a Terracotta-based approach.
1. Terracotta is faster because it hooks into the heap as a JVM plug-in whereas bean-style programming that doesn't use bytecode manipulation uses Java serialization. Terracotta sees fine grained changes to your object graph and pushes only where needed. For example, if you have a web app with 100Kbyte sessions and you change a 25 byte string, Terracotta will push only 25 bytes. If that web app is running 100 nodes under a sticky load balancer, and 2 app instances have been sent session requests, then that 25 bytes will only be sent to those 2 nodes out of 100. Thus, Terracotta is typically 10X or more faster than other solutions, at least according to our customers.
2. Terracotta is simpler again because it hooks in the heap as a JVM plug-in and it honors the Java Memory Model whereas bean-style interfaces that serialize rely on you to redesign your app and all the frameworks you use to get at your domain model through beans. Terracotta works not just for session but any POJO you write and those inside the open source and 3rd party frameworks you use (Spring, Wicket, Rife, EHCache, Struts, Jetty, Tomcat, and more). For example, you can use Weblogic, Websphere, Tomcat, Jetty, or Geronimo without any session clustering and bolt in Terracotta to cluster instead. You can download the kit at http://www.terracotta.org/ and look inside $TC_HOME/samples/pojo. You will see MANY examples that cannot be run on multiple JVMs with any other solution. For example, there are demos that cluster java.util.concurrent. There are demos that share objects across maps and lists and all without Java Serialization.
3. Terracotta is more reliable because it runs outside your process in its own JVM whereas most bean-style solutions run inside your application's process space. Terracotta plugs in to your JVM with some jars / libraries on your machine, but it is also a separate process that acts like a NETWORK ATTACHED MEMORY SERVICE (runs as pure Java on most HW you would want to run it on) and our software can persist everything to disk as well as to any number of backup Terracotta servers. It is more of a non-stop computing platform than others we have seen.
In short: with Terracotta you are not forced into a programming model. And, Terracotta works at a lower level than bean-style solutions and could, in theory, cluster an OSS asynchronous API framework such as CommonJ, SEDA-style frameworks, Blitz, Spring Eventing, etc.
I know we already cluster Quartz and Lucene simply by configuring those two frameworks to use RAM for storing state and then flagging that state as shared across JVMs through Terracotta. I want to take a look at Spring Batch soon. That should be fun.
Simple, eh? I clearly am biased but I do think this approach is a great tool in your arsenal.
Trackback Pings
TrackBack URL for this entry:
http://blog.terracottatech.com/cgi-bin/mt/mt-tb.cgi/12