- All Superinterfaces:
- java.lang.AutoCloseable
- All Known Implementing Classes:
- BigTableWriter, ChecksummedSequentialWriter, ChecksummedSequentialWriter.TransactionalProxy, CompactionAwareWriter, CompressedSequentialWriter, CompressedSequentialWriter.TransactionalProxy, CompressionMetadata.Writer, DefaultCompactionWriter, LifecycleTransaction, MajorLeveledCompactionWriter, MaxSSTableSizeWriter, SequentialWriter, SequentialWriter.TransactionalProxy, SplittingSizeTieredCompactionWriter, SSTableRewriter, SSTableWriter, SSTableWriter.TransactionalProxy, Transactional.AbstractTransactional
public interface Transactional
extends java.lang.AutoCloseable
An abstraction for Transactional behaviour. An object implementing this interface has a lifetime
of the following pattern:
Throwable failure = null;
try (Transactional t1, t2 = ...)
{
// do work with t1 and t2
t1.prepareToCommit();
t2.prepareToCommit();
failure = t1.commit(failure);
failure = t2.commit(failure);
}
logger.error(failure);
If something goes wrong before commit() is called on any transaction, then on exiting the try block
the auto close method should invoke cleanup() and then abort() to reset any state.
If everything completes normally, then on exiting the try block the auto close method will invoke cleanup
to release any temporary state/resources
No exceptions should be thrown during commit; if they are, it is not at all clear what the correct behaviour
of the system should be, and so simply logging the exception is likely best (since it may have been an issue
during cleanup, say), and rollback cannot now occur. As such all exceptions and assertions that may be thrown
should be checked and ruled out during commit preparation.
Since Transactional implementations will abort any changes they've made if calls to prepareToCommit() and commit()
aren't made prior to calling close(), the semantics of its close() method differ significantly from
most AutoCloseable implementations.