~pperalta

Today I read an article comparing Terracotta to Coherence. IMHO these are different products that serve different needs and have very different approaches to clustering. I normally don’t talk about our competitors since I honestly know very little about them. However, I do know Coherence and I thought it would be appropriate to point out the factual errors in this document.

This analysis is not meant to be a point for point rebuttal or an evaluation of which product is “better” (since every use case is unique and I’m a firm believer of using the right tool for the job.) It is simply highlighting what I perceive to be the most glaring inaccuracies.

Unlike Oracle Coherence, Terracotta maintains a coherent data model at scale. To get scale with Oracle Coherence, you have to switch from synchronous updates (slow, but coherent) to asynchronous updates (faster, not coherent).

If you are evaluating Oracle Coherence right now – ask yourself how much out of sync your data can be?

Most users of Coherence use the partitioned cache which does not perform any asynchronous operations. Updates are always made to the primary node and the backup node synchronously. This means that the cost of putting items in the cache will remain constant, whether across 5 nodes or 50. This also means that the data in the cache is never “out of sync.”

Terracotta works with Spring, Hibernate, Quartz, Compass, Lucene, Guice, Camel, Struts, Joda time and more.

This somehow implies that Coherence cannot be used with these other frameworks. Many Coherence customers do in fact use these frameworks (especially Spring and Hibernate) as part of their stack.

Terracotta doesn’t force you to pick your cache strategy upfront. With Oracle Coherence, you need to carefully choose between a Near Cache, a Far Cache, a Replicated Cache, or Partitioned Cache (there’s more, but they have so many models I can’t keep track).

The caching strategy chosen does not require any code changes, as it is all based on configuration. The statement above seems to imply that once you’ve chosen a topology you’re stuck with it, which is wholly inaccurate. It is a bit odd to me that this could be considered a weakness, as I doubt that any off the shelf product can be all things to all people OOTB without taking into account usage patterns and configuring the product appropriately.

In fact, the partitioned cache is a core strength of Coherence, as it allows for

• increased storage capacity to a grid simply by adding nodes
• automatic partitioning of data, which is a key component to scalability
• the ability to send invocations into the grid directly where the data is stored

Terracotta is the only product that gives you High Availability of your data by not only replicating it across servers for redundancy, but also by providing a simultaneous path to disk.

This means unlike Coherence, you can trust your heap, even in the event of a complete cluster failure. Terracotta can truly replace temporal data in the database, to alleviate the bottleneck that databases introduce. Oracle Coherence needs you to buy a database too. I wonder why.

As a matter of fact, there are many Coherence users that don’t use a database at all. In order to provide redundancy, scalability, and no single points of failure, Coherence does not require any disk writes (to an expensive SAN) whatsoever. However, Coherence does provide a means to asynchronously write to a database or any other storage.

I am happy to see a competitive landscape in this area, as it is an indication of the vitality of this market. However (as idealistic as this sounds) I would prefer to have more accurate and factual data out there and less FUD.