Reliable Scheduling of Database Transactions

Get BibTex-formatted data

Author

Marc H. Graham,Nancy Griffeth,Barbara Smith-Thomas

Entry type

techreport

Abstract

A database transaction is usually required to have an "all-or-none" property, that is, either all of its changes to the database are installed in the database or none of them are. This property can be violated by a hardware or software failure occurring in the middle of the execution of a transaction or even by a decision to abort a transaction to avoid an inconsistent (non-serializable) schedule. In such a situation, we must recover from the failure by restoring the database to a state in which the failed transaction never executed. The idea of "recoverable schedules" was defined in [H83]. In a recoverable schedule, a transaction does not commit until there is no possibility that it will be rolled back. If the underlying hardware or software is unreliable, this much not occure until all transactions which have written values read by the transaction have themselves committed.

Date

1983 – October

Address

Atlanta, GA 30332

Institution

Georgia Institute of Technology

Key alpha

Graham

Publication Date

0000-00-00

Location

A hard-copy of this is in the Papers Cabinet

BibTex-formatted data

To refer to this entry, you may select and copy the text below and paste it into your BibTex document. Note that the text may not contain all macros that BibTex supports.

@Techreport{ Graham,
	title = "Reliable Scheduling of Database Transactions",
	author = "Marc H. Graham,Nancy Griffeth,Barbara Smith-Thomas",
	year = "1983",
	month = "October",
	address = "Atlanta, GA 30332",
	institution = "Georgia Institute of Technology",
	abstract = "A database transaction is usually required to have an "all-or-none" property, that
is, either all of its changes to the database are installed in the database or
none of them are. This property can be violated by a hardware or software failure
occurring in the middle of the execution of a transaction or even by a decision
to abort a transaction to avoid an inconsistent (non-serializable) schedule. In
such a situation, we must recover from the failure by restoring the database to
a state in which the failed transaction never executed. The idea of "recoverable
schedules" was defined in [H83]. In a recoverable schedule, a transaction does not
commit until there is no possibility that it will be rolled back. If the underlying
hardware or software is unreliable, this much not occure until all transactions
which have written values read by the transaction have themselves committed.",
}