Browse Prior Art Database

Presumed Commit Protocols

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

Publishing Venue

IBM

Related People

Lindsay, B: AUTHOR [+2]

Abstract

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. In other words, a commit protocol is needed to guarantee the atomicity of distributed transaction executions. Guaranteeing atomicity requires that certain facilities exist in the distributed data base system.

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

Page 1 of 2

Presumed Commit Protocols

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. In other words, a commit protocol is needed to guarantee the atomicity of distributed transaction executions. 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, which is also called "forcing" a log record, 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. An important point to note is that a synchronous write reduces the response time of the writer compared to an asynchronous write. The...