Transaction Processing¶
Gray, J., & Reuter, A. (1992). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
Cited by¶
12 citations across 12 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Batch Processing
- The fixed per-batch cost is the disk seek-and-sync: physically positioning the write head and forcing data to durable storage costs roughly the same whether one record or a thousand is being flushed — a setup independent of batch size.
This sourceStandard reference for group commit and buffered disk writes amortizing the fixed seek-and-sync cost over many records.
- The fixed per-batch cost is the disk seek-and-sync: physically positioning the write head and forcing data to durable storage costs roughly the same whether one record or a thousand is being flushed — a setup independent of batch size.
- Commitment
- In computing, transactions commit or roll back, version-control systems record commits as immutable points in history, and distributed-commit protocols solve agreement on whether a commitment is in force.
This sourceStandard reference on transactional commit/rollback, durability, atomicity, and the two-phase commit protocol for distributed agreement.
- In computing, transactions commit or roll back, version-control systems record commits as immutable points in history, and distributed-commit protocols solve agreement on whether a commitment is in force.
- Fault Tolerance
- The cost-benefit trade-off (hardware, latency, operational complexity vs resilience gain)
This sourceShows how to build high-availability systems 'with finite budgets and risk,' covering fault tolerance and recovery and the cost trade-offs of resilience.
- The cost-benefit trade-off (hardware, latency, operational complexity vs resilience gain)
- Idempotence
- Every idempotence claim names (1) the operation being characterized — a function, a message handler, an API endpoint, a transformation; (2) the state space over which idempotence holds — all inputs, inputs satisfying a precondition, a specific operation type; (3) the mechanism providing the property — natural (set membership query), structural ("set status to shipped" because shipped is terminal), or engineered (idempotency keys, dedup tables, exactly-once semantics over at-least-once delivery); (4) the failure and retry model the property protects against — duplicate delivery, retry storms, replay attacks, eventual consistency; (5) the level at which idempotence holds — state-level (final stored state is identical) versus effect-level (downstream side-effects, notifications, billing events are also identical); and (6) the composition behavior — whether sequences and parallel applications of idempotent operations are themselves idempotent, distinctions consistent with the diagnostic vocabulary developed in Gray and Reuter (1992) for transactional recovery.
This sourceMorgan Kaufmann. Chapters on recovery and idempotent operations in transactional systems; dedup in crash recovery.
- Every idempotence claim names (1) the operation being characterized — a function, a message handler, an API endpoint, a transformation; (2) the state space over which idempotence holds — all inputs, inputs satisfying a precondition, a specific operation type; (3) the mechanism providing the property — natural (set membership query), structural ("set status to shipped" because shipped is terminal), or engineered (idempotency keys, dedup tables, exactly-once semantics over at-least-once delivery); (4) the failure and retry model the property protects against — duplicate delivery, retry storms, replay attacks, eventual consistency; (5) the level at which idempotence holds — state-level (final stored state is identical) versus effect-level (downstream side-effects, notifications, billing events are also identical); and (6) the composition behavior — whether sequences and parallel applications of idempotent operations are themselves idempotent, distinctions consistent with the diagnostic vocabulary developed in Gray and Reuter (1992) for transactional recovery.
- Return Path
- The asymmetric per-unit cost is visible as the logging overhead every write pays to keep rollback possible, and in two-phase commit the abort path is more elaborate than the commit path, coordinating a reversal across all participants.
This sourceDevelops two-phase commit and its abort path, showing the reversal coordination across participants is more elaborate than the commit path.
- The asymmetric per-unit cost is visible as the logging overhead every write pays to keep rollback possible, and in two-phase commit the abort path is more elaborate than the commit path, coordinating a reversal across all participants.
- Sharding
- The cross-shard operation — a transaction touching two users on different shards — is dramatically more expensive (it needs a coordinator and a two-phase commit), so the design minimizes it; "does this operation cross shards?" is the recurring friction diagnostic.
This sourceCanonical treatment of distributed transactions and the two-phase commit protocol, whose coordinator and forced-log/message overhead make a cross-shard transaction dramatically more expensive than a single-shard operation.
- The cross-shard operation — a transaction touching two users on different shards — is dramatically more expensive (it needs a coordinator and a two-phase commit), so the design minimizes it; "does this operation cross shards?" is the recurring friction diagnostic.
- Transaction
- Unity Test
- The unifying relation is co-membership within a
BEGIN…COMMITboundary — the writes are bound into one whole by the relation "issued within the same transaction scope."This sourceStandard treatment of the transaction as a unit of work bounded by BEGIN/COMMIT, conferring atomicity all-or-nothing on a cluster of operations.
- The unifying relation is co-membership within a
Domain-specific¶
- Distributed lock manager
- These architectural variants preserve the same arbitration contract.
This sourceMorgan Kaufmann. ISBN 978-1-55860-190-1.
- These architectural variants preserve the same arbitration contract.
- No-Force Policy
Mechanisms¶
- Optimistic Concurrency Check
- Its strength is high concurrency with no lock contention, and it renders the lost update anomaly impossible to miss rather than silent.
This sourceExplains optimistic concurrency control as allowing concurrent work while detecting conflicting updates so a lost update becomes an explicit conflict.
- Its strength is high concurrency with no lock contention, and it renders the lost update anomaly impossible to miss rather than silent.
- Safe-Commit Hold
- Its strength is decoupling production from propagation: it lets an operation run at full speed while guaranteeing that its output can't hurt anything until vouched for, which is the atomic-commit principle — nothing partially-done becomes visible — applied to any risky release.
This sourceExplains atomic commit as ensuring that a transaction's effects are completed together or not made visible at all.
- Its strength is decoupling production from propagation: it lets an operation run at full speed while guaranteeing that its output can't hurt anything until vouched for, which is the atomic-commit principle — nothing partially-done becomes visible — applied to any risky release.
Verification¶
Does it exist? Not confirmed. The DOI recorded for this work did not resolve when it was last checked, so it is shown above but not linked. The citation may still be sound; the recorded identifier is not. Flagged for repair.
Does it back the claim? Not recorded. Neither this nor any other of the 12 citations of this work carries a recorded support check.
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.
Links previously used in the corpus¶
Before the registry existed this work was also linked 8 other ways.
- https://archive.org/details/transactionproce0000gray ×1
- https://dblp.org/rec/books/mk/GrayR93 ×1
- https://dl.acm.org/doi/book/10.5555/573304 ×1
- https://search.worldcat.org/title/26303792 ×1
- https://www.google.com/books/edition/Transaction_Processing/S_yHERPRZScC ×1
- https://www.google.com/books/edition/Transaction_Processing/VFKbCgAAQBAJ ×1
- https://www.google.com/books/edition/Transaction_Processing/Vfn8s6Vh1V4C ×1
- https://www.google.com/books/edition/Transaction_Processing/VqQQc4_pXFcC ×1
Registry ID ref:a57b3108ff42 · see in the full table