You continue to dodge Nati’s question. You claimed “with Terracotta your objects are on disk at local memory speeds”. Nati asked: “How you can claim that you can persist data at in-memory speed?” (Which isn’t necessarily what you said.) You responded: “Persisting data at in-memory speed is a fundamental Terracotta invention. By being transparent, we get to figure out what is changing and push only deltas ..”

So you get a perfect 10 for dodging the question (and digging yourself a hole ;-) ..

Peace,

Cameron Purdy | Oracle Coherence
http://www.oracle.com/technology/products/coherence/index.html

1. Persisting data at in-memory speed is a fundamental Terracotta invention. By being transparent, we get to figure out what is changing and push only deltas, in big batches to multiple disks for redundancy.

2. We don’t care if a node fails. We have all the data on 2 nodes on disk. We transparently handle failover.

3. “bounded to that specific machine?” What does that mean? We have no problem migrating state from one machine to another using built-in software that allows you to introduce a blank node to the grid, have it image off of another node, and then start doing work. Its quite easy actually. Some of our customers take nodes on and offline in production while serving >10 thousand transactions per second!

–Ari

Maybe i’m missing something.

The argument made here and in recent posts hint that you can get rid of a database with Terracotta right?
If that is the claim then the concerns that i was trying to make are valid.

If you claim that each terracotta node persist its state to disk then that brings lots of other questions.

1. How you can claim that you can persist data at in-memory speed?
2. What happen if one of node fails how do you deal with hot fail-over?
3. If my node becomes persistent to local-disk wouldn’t that mean that it will become bounded to that specific machine?

These are only few of the questions that we had to deal with in the past when we introduced similar approach.
Anyway if there is basic information that i’m missing i’ll appreciate if you could point me (and other readers) to the specific location with the relevant information.

In Terracotta:
1) It is extending parts of your app to the cluster
2) For data that is short to medium lived
3) extends the java memory model/ normal java locking model to the cluster
4) All behavior is executed in client memory.
5) Pluggable modules for integrating with your favorite frameworks

I could see a scenerio where someone would use an OODB and Terracotta. Their is
very little overlap between what one would “Want” to put in a db and what one wants to put
in Terracotta.

Alex miller wrote an excellent few blogs on this topic.
http://tech.puredanger.com/2008/12/07/terracotta-replacing-the-database/

1. Nati – weird that you have feedback and concerns on the “design pattern” espoused in the article as none is actually put forward by the author. Are you actually trying to assert that your product does something better than a design pattern that has not been specified? That’s crazy talk…you don’t even know what it is you are doing better than. If I treat your concerns as generic to “write behind to a database” type approach, then you miss the entire point of the Terracotta approach. We represent durable, transactional network attached memory–with Terracotta your objects are on disk at local memory speeds and thus it suffers none of the risks you question. 10 hours db downtime is not an issue because we have the app mem on disk. transactions to the DB are not the same in the presence of transactional memory like ours because your app won’t lose state even if it loses power, so again not an issue. In general, I would recommend studying up on Terracotta some more.

2. Zubin – Oracle coherence does not compare with Terracotta. The 2 are complementary. Coherence is for large in-memory data distribution and crunching problems. It puts no data on disk anywhere. Terracotta is for enterprise app db offload and simplification. Oracle does not in fact have a solution with Coherence for lowering app costs–Coherence will offload the db but makes the app more cumbersome and you pay Oracle for yet even more software in addition to the DB. Also note for those who will likely want to point out to me that one can pay for Terracotta just as one would pay for Coherence, there’s a difference. With Coherence, our customers who have switched to Terracotta all say they shrunk their DB installation. But when they were using Coherence, since it has no disk-based persistence the same sized Oracle DB one would need to handle all your DB transactions is still needed.

3. Richard – Terracotta is not 30 year old technology. We are network attached memory. We are fine-grained meaning we push only memory-level deltas. And we are runtime optimized meaning we reorder and optimize application locking and transactions so as to eliminate or reduce network I/O to a bare minimum. Show me any technology in the past 30 years that gets into application memory, reorders the app memory operations at runtime like hotspot would do to code, and most importantly produces software transactional memory across threads running across processes on separate machines. You won’t find all those pieces and parts put together ever in the past. In fact Sun published a paper in 1994 saying they wished such a thing existed because it would save lots of developers loads of work. If you assert, instead, that Terracotta uses all the computer science theory invented by the 70′s and 80′s and very little new then I would agree. But that statement is true of almost _all_ algorithms and ideas anyone uses today. Most things developers do were created at Xerox Parc or elsewhere in the 70′s (and earlier). Not sure this means Terracotta is any less interesting or helpful to developers of Java apps struggling to live with ORM and SQL and, most importantly, Oracle.