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.
@author Sun Microsystems, Inc.
@see NestableTransaction
@see net.jini.core.transaction.server.TransactionManager
@see net.jini.core.transaction.server.NestableTransactionManager
@see TransactionFactory
@since 1.0