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.

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

Transaction Manager architecture: User Transactions enter the TM (Scheduler, Lock Manager, Write-Ahead Log, Deadlock Detector, Recovery Manager) and a consistent ACID Database State comes out.

Figure 1. Five components, one guarantee. The scheduler keeps the interleaving conflict-serializable (Consistency); the lock manager enforces 2PL with O(1) hash lookups (Isolation); the WAL logs every change before the data page moves (Durability); the deadlock detector watches the waits-for graph and aborts a victim on a cycle; the recovery manager runs Analysis, REDO, and UNDO after a crash (Atomicity). Together they turn concurrent transactions into one consistent state.

Jump to a component: Scheduler · Lock Manager · Write-Ahead Log · Deadlock Detector · Recovery Manager

Five Components, Four Firing

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: five components, four firing.

Three transactions on different tuples (Mickey blue, Minnie orange, Daffy violet) flow through the Scheduler, Lock Manager, and Write-Ahead Log; the Deadlock Detector stays grey and idle; the Recovery Manager stands by; the result is one consistent committed state.

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

Out of about 1000 concurrent transactions, ~980 touch independent rows (green) and never wait; only 10 to 20 actually conflict (amber). Three design choices keep this cheap: O(1) hash lock checks, a sequential WAL, and separation of concerns. The takeaway: a million transactions per second on commodity hardware.

Figure 3. Most transactions never touch the same row, so most never wait. Out of roughly a thousand concurrent transactions, only ten to twenty actually conflict. A hash table makes each lock check O(1), the WAL turns scattered updates into one sequential stream, and each component does one job behind a tiny interface. That separation of concerns is what lets a database run a million transactions per second on commodity hardware.