Transaction Manager: The Complete Picture

The Full Transaction Manager

How modern databases orchestrate thousands of concurrent transactions

From user requests to crash recovery - the complete system

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!

Scaling to Thousands

Components Working Together

Concurrency Control (2PL/S2PL): Keeps the peace with locking
Recovery (WAL): Guarantees durability, enabling UNDO/REDO
Scheduler: Fine-tunes execution order for peak performance
Deadlock Detector: Cuts through circular waits by aborting transactions

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

The Journey Through This Section

What We Learned

  1. Three Transactions: The interplay of T1, T2, T3
  2. Post-Crash Recovery: UNDO/REDO in practice
  3. This Summary: The complete architecture

Key Concepts

  • Microschedules and timing
  • Lock protocols (2PL, S2PL)
  • WAL and recovery algorithms
  • Deadlock detection and resolution