Chapter 5: Transactions

Introduction

This introduction explains why transactions matter in distributed systems and frames the chapter around correctness and completeness rather than ACID alone.

• Transactions in distributed systems: Explain that transactions originated in database systems but were broadly adopted in distributed systems because they offer an exceptional developer experience.
  Why it matters: Their database origins help explain why the chapter introduces transactions before turning to distributed transactions.
• Certainty amid concurrency and failure: Describe the central promise of transactions: they provide certainty by letting developers act as though concurrency or failure does not exist.
  Why it matters: This promise motivates the chapter’s examination of what transactions guarantee.
• Correctness and completeness lens: Distinguish the chapter’s proposed lens of correctness and completeness guarantees from the customary presentation of ACID as four separate properties: atomicity, consistency, isolation, and durability.
  Why it matters: This framing tells the reader how the chapter will build a holistic mental model of transactions.

Key terms: transactions, database systems, distributed systems, developer experience, concurrency, failure, certainty, ACID, atomicity, consistency

5.1 Abstractions

This section explains how layered abstractions translate between different kinds of entities while preserving results, then introduces transactions as an abstraction over concurrency and failure.

• Transformative layered abstractions: Explain how a higher layer turns lower-level entities into a different interface, and how that interface can become the lower-level input to another layer. Use the hardware–operating system–database example.
  Why it matters: Transactions make more sense when you see them as one layer in a stack of abstractions.
• Cross-level translation and equivalence: Describe how an API maps concepts between levels with different entities and semantics. Explain top-down reduction, bottom-up composition, and the expectation that reasoning at either level yields the same result.
  Why it matters: The abstraction is useful only if its higher-level view corresponds to what the lower-level system does.
• Transactions as protective abstractions: Explain that transactions let us define work as though concurrency and failure do not exist, while the underlying execution must handle concurrency and tolerate failure.
  Why it matters: This is the perspective the chapter uses to examine what transactions promise and what their implementation must handle.

Key terms: abstraction, higher-level abstractions, lower-level abstractions, primitive expressions, API, agnostic, aware, reduction, composition, equivalence

5.2 The magic of transactions

This section introduces transactions as the reason a money-transfer web handler can appear simple despite the concurrency and failure risks of a distributed application.

• Transactions hiding distributed complexity: Explain that web applications are distributed applications, but a transactional database can extend correctness and completeness guarantees to the application, hiding much of the concurrency and failure handling that distribution would otherwise require.
  Why it matters: This explains why application code can look simpler than the distributed system it runs in.
• Unguarded money-transfer handler: Describe the simplified /transfer endpoint and identify the guardrails absent from its visible handler: detection or mitigation of concurrency and failure.
  Why it matters: The example makes the hidden work of transactions concrete.

Key terms: transactions, correctness, completeness, concurrent, partially synchronous distributed system, unreliable network, /transfer endpoint, source identifier, target identifier, amount

5.2.1 Concurrency

The section shows how concurrent read-and-write operations can produce an incorrect account balance and how transactions hide that concurrency from a query.

• Concurrent balance update race: Trace how two concurrent transfers can produce an incorrect balance when each transfer reads and then writes the same account.
  Why it matters: The balance example makes the correctness problem that transactions address concrete.
• Transactional concurrency abstraction: Explain that transactions guarantee correctness by making operations execute as though concurrency does not exist, even when the query shows no explicit race-condition handling.
  Why it matters: This is the abstraction the section offers in place of reasoning about every possible interleaving in a query.

Key terms: race condition, read operation, write operation, interleaving, concurrent transfers, transactions, correctness, concurrency, race conditions

5.2.2 Failure

A two-account transfer shows how a failure between writes can leave a partial result, while a transaction guarantees a complete outcome without requiring the developer to handle that failure explicitly.

• Partial transfer after failure: Trace how a failure between the two writes of an account transfer can leave one balance updated and the other unchanged.
  Why it matters: The partial transfer makes the failure problem that transactions solve concrete.
• Transaction completeness despite failure: Explain that transactions guarantee completeness despite failure, even though the query contains no visible failure-detection or mitigation steps. State the section’s broader conclusion that transactions also guarantee correctness despite concurrency without making the developer express those concerns in the transaction definition.
  Why it matters: This is the abstraction that lets developers specify the transfer without spelling out how to handle interruptions.

Key terms: write operations, partially applied, source account, target account, transactions, completeness, correctness, concurrency and failure-agnostic definition

5.3 The model of transactions

This section defines a transaction, introduces its ACID guarantees, and models how a program becomes an execution whose actions can be traced alongside other transactions.

• Transaction boundaries and ACID guarantees: Explain that a transaction is a sequence of operations on objects ending in exactly one commit or one abort, and describe the atomicity, consistency, isolation, and durability guarantees.
  Why it matters: These guarantees establish what a transaction promises before the book examines how it delivers those promises.
• Application-defined consistency rules: Distinguish consistency as an application-level guarantee from the platform-level guarantees of atomicity, isolation, and durability, using the account-balance constraint example.
  Why it matters: The distinction shows why the same operation may commit or abort under different application rules.
• Program definition and transaction execution: Distinguish a program as a sequence of operations on names from a transaction as the execution of those operations on objects, ending in commit or abort.
  Why it matters: Separating the definition from its execution makes the later transaction model easier to follow.
• Transaction traces and histories: Describe a transaction trace as ordered triples identifying the transaction, operation, and object, and a history as the execution of a set of transactions whose actions may interleave.
  Why it matters: Traces and histories give the book a way to reason about actions from multiple transactions.
• Failure-aware transaction execution: Explain that the database system translates a failure-agnostic program definition into a failure-aware, failure-tolerant execution to guarantee correctness and completeness.
  Why it matters: This translation connects the simple program definition to the guarantees expected of its execution.

Key terms: transaction, commit, abort, ACID, atomicity, consistency, application-level guarantee, platform-level guarantees, CHECK clause, program

5.3.1 Correctness

The section explains how a database can execute transactions concurrently while preserving correctness by making their combined effects equivalent to a serial execution.

• Consistent transaction boundaries: Explain that a transaction starts and ends with a consistent database state, even though its intermediate steps may temporarily violate consistency, as when a transfer debits one account before crediting another.
  Why it matters: Distinguishing intermediate states from transaction boundaries makes the concurrency problem easier to see.
• Serial execution as baseline: Explain why running individually correct transactions one after another preserves consistency and avoids concurrency anomalies, whereas concurrent transactions can expose one another's intermediate inconsistencies.
  Why it matters: Serial execution gives a concrete baseline for deciding whether concurrent behavior is correct.
• Serializable concurrent effects: Explain that a database system handles concurrency anomalies so developers can define transactions without accounting for their interleavings; concurrent transactions are correct when their combined effects match one of the possible serial orders.
  Why it matters: Serializability states the correctness guarantee that lets transactions overlap without introducing database inconsistencies.

Key terms: consistent state, precondition, postcondition, Hoare triple, serial history, sequential composition, concurrency anomalies, serializability, concurrency-agnostic definition

5.3.2 Serializability

Defines serializability as a correctness test for concurrent transactions and sketches how locking can enforce it while permitting concurrency.

• Consistency models as history predicates: Explain that a consistency model classifies execution histories as valid or invalid and expresses a system’s correctness guarantee.
  Why it matters: This makes clear what serializability is a test of.
• Serial equivalence of concurrent transactions: Explain that a concurrent execution is serializable when its transaction results and database state are equivalent to those of some sequential ordering of the same transactions, not necessarily one particular ordering.
  Why it matters: Serializability lets transactions overlap without giving up the specified sequential outcome.
• Lock granularity and concurrency: Describe how one lock guarding all objects trivially enforces serializability by forcing sequential execution, while finer-grained locks can allow concurrent schedules that retain sequential semantics. Explain that the difficulty is allowing as much concurrency as possible without losing that guarantee.
  Why it matters: The challenge is not merely to enforce serializability, but to do so efficiently.

Key terms: consistency model, execution histories, correctness guarantees, serializability, concurrent execution, sequential execution, transaction result, database state, one lock, fine-grained locks

5.3.3 Completeness

The section explains how a database makes transactions complete despite failures, focusing on Undo logging and the resulting commit and abort traces.

• Failure tolerant completeness: Explain that the database turns a failure-agnostic transaction definition into a failure-aware, failure-tolerant execution by detecting and mitigating failures for the developer. Distinguish backward recovery, called Undo, from forward recovery, called Redo, while noting that this section focuses on Undo.
  Why it matters: Completeness explains why developers can define a transaction without handling every failure themselves.
• Undo log ordering: Describe how each transaction operation has a corresponding Undo operation, which the database records in the Transaction Undo Log before executing the original operation.
  Why it matters: Recording the reversal first gives the database a way to undo an operation if execution fails.
• Commit and abort traces: Trace the two valid transaction outcomes: a commit executes all regular operations without failure, while an abort executes some operations and then undoes them in reverse order to restore the pre-transaction state. State that the section distinguishes application-level abort from the more challenging platform-level abort.
  Why it matters: The two traces show what successful completion and recovery must accomplish.

Key terms: completeness, failure-agnostic, failure-aware, backward recovery, Undo, forward recovery, Undo operation, Transaction Undo Log, ou, commit trace

5.3.4 Application-level abort

This section distinguishes explicit and implicit application-level aborts and states that the database undoes the aborted transaction's operations.

• Application-level abort paths: Distinguish an explicit abort, triggered by an abort command, from an implicit abort, triggered automatically by a condition such as a consistency violation. Explain that the database performs the transaction's Undo operations in either case.
  Why it matters: The distinction explains how a transaction can end without committing and what the database does afterward.

Key terms: application-level abort, explicit abort, implicit abort, consistency violation, Undo operations

5.3.5 Platform-level abort

This section explains how a database recovers uncommitted transactions after a crash and why Undo operations must remain safe across repeated restarts.

• Platform-level abort recovery: Describe how a crash and restart can abort a transaction at any point, and how the database recovers by finding uncommitted transactions in its Transaction Undo Log and performing their Undo operations.
  Why it matters: Recovery must remove the effects of transactions that had not committed when the database crashed.
• Restartable Undo operation requirements: Explain why a crash between recording and performing an Undo, or during recovery, can cause Undo to run before the original operation or run multiple times. Describe the required noop and idempotent properties in terms of their effects on an object.
  Why it matters: These properties let recovery be retried without changing the intended result.

Key terms: platform-level abort, recovery, Transaction Undo Log, uncommitted transaction, Undo operation, restartable, noop, idempotent

5.4 Summary

The summary presents transactions as layered abstractions that let applications act as though concurrency and failure do not exist while the database handles both underneath.