Transaction Processing

Gray, J., & Reuter, A. (1992). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.

Type

Book

Intellectual base

Review or monograph

Year

1992

DOI

10.5555/573304

Link

https://archive.org/details/transactionproce0000gray

Cited from

computer_science, engineering_design, mathematics, operations_research, philosophy

Cited by

10 citations across 10 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• Transaction
  • The essential commitment is that systems performing multi-step state changes must guarantee that failures, concurrency, and interleavings do not leave observable intermediate or inconsistent states, that atomic commit / rollback is the primary tool for this guarantee, and that the cost of providing these guarantees scales with the desired strength of isolation and durability
• Unity Test
  • The unifying relation is co-membership within a BEGIN…COMMIT boundary — 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.

Domain-specific

• Distributed lock manager
  • These architectural variants preserve the same arbitration contract.

    This sourceMorgan Kaufmann. ISBN 978-1-55860-190-1.

• No-Force Policy
  • Dirty data pages can be written later according to buffer pressure, background writeback, checkpointing, or other scheduling policy.

Verification

This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 6 other ways.

• 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