Principles of Transaction-Oriented Database Recovery.¶
Haerder, T., & Reuter, A. (1983). Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4), 287-317.
Cited by¶
7 citations across 7 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Commitment
- The release/breach invariants appear as the transaction's alternative — ROLLBACK before commit discharges the tentative state at no cost, while a failure after commit cannot quietly retract the writes; durability guarantees they persist even through a crash, which is the cost-on-breach made absolute.
This sourceDefines the ACID properties — including atomicity and durability — that make a database COMMIT an absolute, irrevocable bind.
Supported in partVerified against the work's full text
Garbled fragments show a transaction is executed indivisibly, resets on abort, and once committed its results must survive failure; commitment-theory framing is absent.
“commits, all of its results must survive any”
- The release/breach invariants appear as the transaction's alternative — ROLLBACK before commit discharges the tentative state at no cost, while a failure after commit cannot quietly retract the writes; durability guarantees they persist even through a crash, which is the cost-on-breach made absolute.
- Data Integrity
This sourceCoins the ACID acronym (atomicity, consistency, isolation, durability) and gives a unified terminology for transaction recovery. Appears only in the references list (appended to the codd-1970 entry), never cited in the body.
- Relation
- Listed in the references but not attached to a specific claim.
- Set and Membership
- Listed in the references but not attached to a specific claim.
- Transaction
- The unit of work — scope boundary defining which operations are atomic (statements, API calls, distributed steps, workflow)
Supported in partVerified against the work's full text
The paper frames a transaction as the indivisibly executed unit of user activity, but does not enumerate scope levels such as statements, API calls or workflows.
“executed indivisibly: Either all actions are”
- The unit of work — scope boundary defining which operations are atomic (statements, API calls, distributed steps, workflow)
- Unity Test
- The whole-licensed predicates are exactly the point: "the transaction committed," "the transaction was isolated from concurrent readers," "the transaction was durable" are predicates that make sense only of the whole, not of any constituent write
This sourceDefines the ACID properties — atomicity, consistency, isolation, durability — the whole-level predicates a committed transaction confers on its constituent writes.
Supported in partVerified against the work's full text
Haerder and Reuter describe a transaction as isolated, indivisible and durable once committed, but the text does not state the claim's point that these predicates apply only to the whole.
“The transaction basically re- flects the idea that the activities of a par- ticular user are isolated from all concurrent activities”
- The whole-licensed predicates are exactly the point: "the transaction committed," "the transaction was isolated from concurrent readers," "the transaction was durable" are predicates that make sense only of the whole, not of any constituent write
Mechanisms¶
- Database Transaction
- Its strength is that atomicity, consistency, isolation, and durability
This sourceDefines ACID transaction properties and the system mechanisms that let a multi-operation transaction be treated as an all-or-nothing unit.
- Its strength is that atomicity, consistency, isolation, and durability
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 3 of 7 citations: 3 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:762fb334ef91 · see in the full table