Transaction Manager: The Complete Picture

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.

The Architecture

Transaction Manager: Processing 1000s of Concurrent Transactions User Transactions T1, T2, T3... BEGIN UPDATE accounts... COMMIT/ABORT Transaction Manager Scheduler • Reorders operations for performance • Maintains conflict-serializability • Optimizes I/O patterns From: transaction-scheduling Lock Manager (2PL/S2PL) • Prevents conflicts via locking protocol • Hash table for O(1) lock checks • Manages lock queues & priorities From: locks-2pl, microschedules Write-Ahead Log • Log before data (durability) • Sequential writes (100x faster) • Old/new values for UNDO/REDO • Source of truth for recovery From: recovery-wal Deadlock Detector • Builds wait-for graph continuously • Detects cycles in real-time • Chooses victim to abort (youngest) • Prevents system gridlock From: locks-deadlock Recovery Manager • Analysis: Scan WAL to find active transactions at crash • REDO: Replay committed work (forward through log) • UNDO: Reverse incomplete transactions (backward through log) From: recovery-postcrash Database State + ACID Guaranteed Atomic Consistent Isolated • Durable Performance 1000s TXNs/sec <10ms latency 10-20 actual conflicts 99.999% uptime System Crash!

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