Link Details

Well-written, and Terracotta is an interesting tool -- but still, this is a pitch from the co-founder of the company, hence not exactly a balanced view or outside developer "from the trenches" kind of useful.

Since this is the insider view, I'd be more curious about some of the problems they've run into implementing it, plus discussion into the dangers associated with pseudo-transparent inter-JVM thread coordination as opposed to more explicit approaches -- "pseudo"-transparent, because transparent doesn't seem like the right word -- obviously, as a developer you cannot pretend the remote Thread coordination will function identically to the same thing in the local JVM, and you have to plan for that... even if the invoking code looks the same, you have to know it's different behind the scenes, just like when writing an application with a "transparent" interface to both local files and remote files over a possibly-slow or unreliable connection you have to account for that.

I'm not saying they're taking the "wrong" approach -- just saying it's the grayer areas that are interesting.

First of all, great write up. Concise and clear – which is not always the case when reading about Terracotta. “This is not an object cache” cuts both ways though. Yes, Terracotta is not an object cache – and it is not but any stretch of imagination... It is a tool (JVM clustering) that can be at best used to start building a distributed object cache.

I don't know whether it is bad or good and I'm sure it depends on your views. In *my* view Terracotta has a very narrow sweet spot (but when it fits – it fits really like a glove): if you need distributed data caching you will likely choose Coherence, GigaSpaces, JBoss Cache or EHCache. If you need grid computing you may choose GridGain or DataSynapse, for example. And if you are about to roll our your own data caching or grid computing solution – then (!) Terracotta can be indispensable tool as a ready-to-use low-level clustering framework. But how often do you have this need and why would you roll something like that on your own? I don't know...

My biased $0.02,
Nikita Ivanov.
GridGain – Grid Computing Made Simple

Well I'll throw my biased opinion in as well. Often people force their app to use a cache or db because it's the only tool they have for distributing data and coordination. These approaches force people to mangle their object model and their programming model. It's been my experience that most multi-node apps can benefit from the coordination, sharing and availability provided by a solution like this.

Nikita: I urge you to look at the Terracotta Integration Modules. For those, like you, who absolutely want an API, Terracotta works under such a model...including Hibernate 2nd level caching, EHCache clustering, JBossCache bolt-on replacement that runs >10X faster (100X according to real users).

JTheory: I was at a conference in Vegas last week. A production user of Terracotta said that one of the Spring guys (he wouldn't say who) was asserting that what TC does on synchronized{} boundaries is dangerous and hard to use. The TC user said he got very frustrated trying to explain how the natural language meant that he could unit test w/o TC, add TC and re-test to confirm proper behavior. It was clear the Spring engineer had never used TC but that engineer kept arguing. The TC user tried to explain how TC's lock profiler tools, cluster performance optimization tools and the like made life easier with TC than with proprietary clustered caches, etc. I think it would be a mistake to represent TC as perfect and flawless and zero-complexity. TC is not perfect. But I think the power of working with Java Language constructs and honoring the memory model is much more valuable than some appreciate. Clustering is hard, sure, but TC is likely the easiest approach. Have you tried using TC? I would grab the 2.6 nightlies and take a look at all the tools (including Hyperic integration, and cluster performance snapshots).