Browse Prior Art Database

Presumed Abort Protocols

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

Publishing Venue

IBM

Related People

Lindsay, B: AUTHOR [+2]

Abstract

This invention relates to a method for achieving synchronization of recoverable states among multiple nodes in spite of faults. A distributed transaction involving one or more data base sites may be manifest as a hierarchy of processes. The hierarchy is rooted in a coordinator of the transaction with other processes being tree-graph related. When the processes complete their activities, a commit protocol is invoked. Presumed abort (PA) is an extension of the two-phase (2P) commit protocol. PA is optimized for read-only transactions and a class of multi-site update transactions. The optimizations result in reduced inter-site message traffic and log writes, and, consequently, a better response time for such transactions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 3

Presumed Abort Protocols

This invention relates to a method for achieving synchronization of recoverable states among multiple nodes in spite of faults. A distributed transaction involving one or more data base sites may be manifest as a hierarchy of processes. The hierarchy is rooted in a coordinator of the transaction with other processes being tree-graph related. When the processes complete their activities, a commit protocol is invoked. Presumed abort (PA) is an extension of the two-phase (2P) commit protocol. PA is optimized for read-only transactions and a class of multi-site update transactions. The optimizations result in reduced inter-site message traffic and log writes, and, consequently, a better response time for such transactions. In a distributed data base system, the actions of a transaction (an atomic unit of consistency and recovery) may occur at more than one site. When a transaction execution starts, the whole transaction need not be already specified and made known to the system. A distributed transaction commit protocol is required in order to insure either that all the effects of the transaction persist or that none of the effects persist, despite site or communication link failures and loss of messages. Guaranteeing atomicity requires that certain facilities exist in the distributed data base system. It is assumed that each process is able to provisionally perform the actions of a transaction in such a way that they can be undone if the transaction is or needs to be aborted.

Also, each site has a log which is used to recoverably record the state changes of the transaction status during the execution of the commit protocol, and its changes to the data base during execution. The log records are written sequentially in a file which is kept in stable (non-volatile) storage. When a log record is written, the write can be done synchronously or asynchronously. In the former case, that log record and all preceding ones are immediately moved from the virtual memory buffers to stable storage. The log writer is not allowed to continue execution until this operation has completed.

This means that if the site crashes (assuming that a crash results in the loss of the contents of the virtual memory) after the force-write has completed, then the forced record and the ones preceding it would have survived the crash, and would be available for reading from the stable storage when the site recovers. On the other hand, in the asynchronous case, the record gets written to the buffer storage and is allowed to migrate to the stable storage later on (due to a subsequent force or when a log page buffer fills up).

The writer is allowed to continue execution even before the migration takes place. This means that if the site crashes after the log write, then the record may not be available for reading when it recovers. Some of the desirable characteristics for a commit protocol are: (1) guaranteed transaction atomicity always, (2) abil...