Transaction Manager: The Architecture
Concept. The transaction manager coordinates concurrency, logging, and recovery.
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 the log, then undo unfinished transactions). One coherent execution, five cooperating components, ACID preserved.
You assembled these pieces at the close of the Transactions module, in Connecting It All Together. This page is the reference architecture: the whole Transaction Manager in one diagram. The next page runs it: Three Transactions traces a concrete execution. Recovery itself, the two-pass algorithm, you saw in the last section.
The Architecture
Figure: Five components of a transaction managerFive neutral rows show scheduling, locking, logging, deadlock detection and recovery. These cooperate; ACID properties do not map one-to-one to components.
Figure 1. Scheduling and locking provide isolation. Logging and recovery support atomicity and durability; deadlock detection breaks cycles of waiting. Application logic and constraints preserve consistency.
Jump to a component: Scheduler · Lock Manager · Write-Ahead Log · Deadlock Detector · Recovery Manager
A No-Conflict Trace
Watch the components run together on a no-conflict trace. Mickey buys Premium, Minnie updates her profile, and Daffy adds a song, all at the same instant. Because the three touch different tuples, the deadlock detector has nothing to do: no transaction waits.
Figure: A no-conflict trace: three transactions on different tuples flow through the Transaction Manager, four of the five components fireThree transactions arrive at the same instant: Mickey buys Premium (blue), Minnie updates her profile (orange), Daffy adds a song (violet). They touch different tuples. The Scheduler routes each to a thread. The Lock Manager grants all three locks with no waiting because the tuples do not overlap. The Write-Ahead Log records each change before commit. The Deadlock Detector stays quiet, the only one of the five that does not fire, because there is no waits-for cycle. The Recovery Manager stands by. The result is one consistent committed state. Color key: blue is Mickey's transaction, orange is Minnie's, violet is Daffy's; green is a component that fired; grey is the Deadlock Detector, idle on this trace.
Figure 2. One coherent execution. The scheduler routes each transaction to a thread, the lock manager grants all three locks with no waiting (the rows do not overlap), and the WAL logs every change before its commit becomes durable. The deadlock detector stays quiet because there is no waits-for cycle, and the recovery manager only acts if the server crashes. ACID preserved.
Why It Scales
Figure: Why the Transaction Manager scales: most transactions touch different data, so few of them ever conflictAn example workload has mostly independent transactions and a small group that conflicts. Hash-based lock checks and sequential logging reduce overhead. Actual throughput depends on the workload and hardware.
Figure 3. In this example, most transactions access different rows. Actual contention depends on the workload; hash-based lock checks and sequential logging reduce overhead.