Browse Prior Art Database

Direct Commit Protocols for Distributed Transaction Processing

IP.com Disclosure Number: IPCOM000048062D
Original Publication Date: 1981-Dec-01
Included in the Prior Art Database: 2005-Feb-08
Document File: 3 page(s) / 71K

Publishing Venue

IBM

Related People

Eswaran, K: AUTHOR [+3]

Abstract

This invention relates to an asynchronization method in a distributed system of communicating nodes in which each transaction to be processed requires either a uniform COMMIT or ABORT response at all nodes. That is, it relates to a distributed system comprising tightly coupled hosts of diminished autonomy under one management. Performance is improved by using a direct commit (DC) protocol, in which slave nodes cannot veto a transaction. However, there exists potential for failure in the slave nodes and the communications medium. This invention contemplates a system having two-phase locking with exclusive and share locks used for each transaction. Furthermore, it contemplates that no updates are performed on the recoverable database state until transaction COMMIT.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 56% of the total text.

Page 1 of 3

Direct Commit Protocols for Distributed Transaction Processing

This invention relates to an asynchronization method in a distributed system of communicating nodes in which each transaction to be processed requires either a uniform COMMIT or ABORT response at all nodes. That is, it relates to a distributed system comprising tightly coupled hosts of diminished autonomy under one management. Performance is improved by using a direct commit (DC) protocol, in which slave nodes cannot veto a transaction. However, there exists potential for failure in the slave nodes and the communications medium. This invention contemplates a system having two-phase locking with exclusive and share locks used for each transaction. Furthermore, it contemplates that no updates are performed on the recoverable database state until transaction COMMIT. Still further, the invention assumes that a list of all updates performed by a transaction is available to the COMMIT coordinator.

Two versions of the DC protocol (DC1 and DC2) together with a recovery protocol for each are described: The DC1 protocol steps include:

1. Commit coordinator (CC) stably recovers sufficient

data to redo all of the transaction's updates.

2. CC sends commit message to slaves and begins making

its own database changes.

3. Each slave records its updates in such a way that

it knows the order in which a transaction is committed

at that slave.

4. The slave acknowledges entry into the committed state

to the CC, and begins making the required database

changes.

5. When the CC has received all the acknowledgements,

and has made all its own updates, it discards its

log (returns the transaction to the idle state),

and sends a message to the slave that this has

occurred.

6. Upon receipt of such a "FINISH" message, and when

through updating its own database, the slave can

dispose of its local transaction log, thereby

entering the idle state.

As in other log management schemes, the log for a transaction cannot be disposed of until all previous transactions have been returned to the idle state. Otherwise, at site restart, those transactions have been returned to the idle state.

The recovery protocol for DC1 is: Upon restart, a slave node requests all the update data records from potential C hosts for all transactions touching the slave and known to the CCs. It makes the required changes in the order determined by its local transaction log, and only then does it make changes for any transactions not appearing in the local log. One can easily see that, because such transactions must have held locks on the updated objects at the time of node failure, there can be no interference between such unknown transactions and...