Transaction Manager: The Architecture

Concept. A Transaction Manager is the orchestrator that runs scheduling, locking, write-ahead logging, deadlock detection, and recovery as one cooperating system, making thousands of concurrent transactions look like each ran alone, with the database in a consistent state at every moment.

Intuition. When Mickey buys Premium while Minnie updates her profile and Daffy adds a song, the TM routes each one through the scheduler (interleave for throughput), the lock manager (block them only on rows they share), the WAL (log every change before it touches the data), and, if the server crashes, the recovery manager (replay committed work, roll back the rest). One coherent execution, four cooperating components, ACID preserved.

This page maps out the components of the TM. The next two pages walk through what they do in practice: Three Transactions traces a concrete execution, and Post-Crash Recovery walks through the three-pass recovery algorithm.

The Architecture

Why It Scales

The Magic of Independence

Most transactions operate on different data. Consider a bank with 1M accounts:

  • Transaction on account #47893 is irrelevant to account #82456
  • Out of 1000 concurrent transactions, only 10-20 might actually conflict
  • Lock manager utilizes hash tables for O(1) lock checks
  • WAL ensures sequential writes even amidst random transaction patterns