What transactionality guarantees does Terracotta provide?
In DSO, the batch of changes made to the clustered object graph within the boundaries of a lock (begin/end of a “synchronized” block of java code, ReentrantReadWriteLock lock(), OR begin/end of a cluster-wide “named-lock”) are replicated (to the Terracotta-Server and other nodes in the cluster which have a reference to that object) either in an Asynchronous or Synchronous mode. Terracotta DSO passes the classic ACID (Atomic, Consistent, Isolated, Durable) test. DSO does not support semantics of an external transaction manager such as JTA or Spring JdoTransactionManager. There is no notion of a “rollback” in the Java-heap, if a transaction fails. DSO could define a non-natural-Java behavior here, but wants to hear from the community before implementing road-map features around this.
