A distributed transaction is a transaction including operation or work items that are performed by multiple nodes, often implemented at multiple networked computer systems. Distributed transactions arise in a number of different contexts. For example, processing an employee's paycheck may involve a distributed transaction with work items performed by nodes at a number of individual computer systems. An employer payroll system node may request a transfer from its own account to the account of the employee. A node at the employer's bank may debit the employer's account by the amount of the transfer. A node at the employee's bank may credit the employee's account by the amount of the transfer. In another example, booking travel may involve a distributed transaction. A travel agent system node may request reservations on various flights, hotels, etc. In response to the requests, one or more airline system nodes may book flight tickets for a traveler. One or more hotel system nodes may create reservations for the traveler, etc.
In distributed transactions, it is often desirable to satisfy the properties of Atomicity, Consistency, Isolation and Durability, known commonly as ACID properties. A distributed transaction satisfying the Atomicity property either successfully executes to completion or fails completely. Referring to the paycheck processing example, if the employer's bank system crashes or otherwise fails to debit the employer's account, Atomicity would require that the bank system be prevented from completing the transfer to the employee's account. A transaction meeting the Consistency property does not violate integrity constraints of any shared resources. The Isolation property requires that intermediate effects of the transaction are not detectable to concurrent transactions. The Durability property requires that changes to shared resources due to the transaction are permanent.
To ensure the Atomicity property, all participants of the distributed transaction coordinate their actions so that they either unanimously abort or unanimously commit to the transaction. For example, a transaction manager may enforce Atomicity by coordinating a distributed transaction according to an atomic commit protocol. Atomic commit protocols typically have multiple phases. In a first phase, commonly known as a prepare phase, the transaction manager asks all other nodes participating in the transaction whether they will commit to the transaction. Nodes commit to the transaction by obtaining appropriate locks for transaction resources, executing a transaction operation or operations, and holding the resource locks until the transaction manager either completes or aborts the transaction. In a subsequent phase, commonly known as the commit phase, the transaction manager determines whether all nodes in the transaction have committed. If all nodes have committed, then the transaction manager completes the transaction, allowing the nodes to release their locks. If the transaction is aborted, the participating resource managers roll-back their operations and then release their locks. Accordingly, Atomicity is satisfied because all of the transaction operations are either completed, or not completed.
USPTO Backgrounds
USPTO Backgrounds