Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Terracotta has a persistent mode where changes are written to disk. This sounds great, but I wonder if it can be relied on to the extent of replacing a standard database? I wonder three things primarily:
1. Does this plug in at all with transaction APIs, such as JTA? Most of our enterprise code relies on the fact that it can rollback the current transaction and have all changes since the beginning of the transaction, well, rollback. Also, our code has multiple resources participating in the transaction, so they all must commit and rollback together.
2. Most enterprise DBs support transaction isolation options to better control concurrent access to data. Most of the time, and depending on the isolation level of the transaction, this allows multiple clients/threads to access the same data at the same time without locking. Does Terracotta provide such concurrency, or do I have to manage locks at a fine grain level to approach this?
3. Does Terracotta's persistance mechanism guarantee consistency? If the plug is pulled on the server in the middle of a transaction, will Terracotta handle this with the same robustness as an enterprise DB?

I realize that Terracotta's persistence mechanism is probably not designed to replace an enterprise DB (this would be quite impressive), but this doesn't rule it out for us. Another option would be if Terracotta had a "pluggable" persistence mechanism (this is probably answered in the documentation somewhere, so I should probably just go RTFM). This way I could plug in an implementation that would use Hibernate to persist objects to a DB when they change, and reload them from the DB if the server is restarted. Yes, a pluggable persistence API isn't entirely necessary, since a client could simply directly invoke Hibernate, but a pluggable mechanism would avoid the client having to manually determine when to do so (the server is always aware of exactly what changes and when). This pluggable persister wouldn't even have to replace Terracotta's merchanism entirely: all that is really needed is an event or hook whenever Terracotta's server has a change committed.

Terracotta passes the ACID (Atomic, Consistent, Isolated, Durable) test. Configuration can be exposed to ensure that changes from the client app-server to the Terracotta-server (L2) are persisted synchronously (currently by default, they are persisted asynchronously - failure to persist to the L2 results in a retry). To answer your specific questions:
1.
Currently there is no integration with JTA and/or other transaction managers. This feature of mapping Terracotta transaction boundaries (i.e. acquisition/release of a lock) to transaction boundaries defined by an external transaction manager is being discussed and will probably be added to the mid-term roadmap.
2.
Lock control with Terracotta can be fine-grained (i.e. map to the begin/end of a synchronized block-of-code or a "named lock" which maps to a method). Additionally objects that have low level synchronization semantics (java.util.concurrent, atomic classes of JDK15) are supported. Additionally one can define read (multiple readers, no writer), write (1 writer alone) or concurrent (no locking) types of locks. One does need to configure such that the locking is not too coarse-grained - and if the application supports read/concurrent access then utilize those types of locks by all means.
3.
Terracotta is dependent on the underlying persistence mechanism's guarantees - what ships by default is the SleepyCat Db configuration set such that it persists to disk on Commit.

Good points wrt pluggable persistence. Its something that's been discussed often and fairly easy to implement - in that the implementation is factored out so as to be able to easily use another persistence API instead of the default SleepyCat persistence API. Its on the long-term roadmap.
If you are working off open code, then there are several interfaces that need to be implemented plus one needs to be well versed with the object DNA format DSO uses - so I'd also add a word of caution that it is not a trivial undertaking.

Hope this is useful. If it helps, send me a PM and we could chat/email some more to discuss your app and if there are workarounds for some of the product gaps we've highlighted in this exchange...
Regards
Iyer.