Interface for classes representing transactions returned by
TransactionManager
servers for use with transaction participants that implement the default transaction semantics.
The semantics:
The overall effect of executing a set of sibling pure transactions concurrently is always
equivalent to some sequential execution.
Ancestor transactions can execute concurrently with child transactions, subject to the locking
rules below.
Every transactional operation is described in terms of acquiring locks on objects; these locks
are held until the transaction completes. Whatever the lock rules are, conflict rules are
defined such that if two operations do not commute, then they acquire conflicting locks. A
transaction can acquire a lock only if the conflicting locks are those held by ancestor
transactions (or itself). When a subtransaction commits, its locks are inherited by the parent
transaction.
If an object is defined to be created under a transaction, then the existence of the object is
only visible within that transaction and its inferiors, but will disappear if the transaction
aborts. If an object is defined to be deleted under a transaction, then the object is not
visible to any transaction (including the deleting transaction) but will reappear if the
transaction aborts. When a nested transaction commits, visibility state is inherited by the
parent transaction.
Once a transaction reaches the VOTING
stage, if all execution under the transaction
(and its subtransactions) has finished, then the only reasons the transaction can abort are: the
manager crashes (or has crashed); one or more participants crash (or have crashed); or an
explicit abort.
Transaction deadlocks are not guaranteed to be prevented or even detected, but managers and
participants are permitted to break known deadlocks by aborting transactions.
An orphan transaction (it or one of its ancestors is guaranteed to abort) is not guaranteed to be
detected.
Causal ordering information about transactions is not guaranteed to be propagated.
As long as a transaction persists in attempting to acquire a lock that conflicts with another
transaction, the participant will persist in attempting to resolve the outcome of the transaction
that holds the conflicting lock.