Three Transactions, Three Variables 🔄
🎯 How a TM Works
How a Transaction Manager handles thousands of concurrent transactions using logs and locks
See the interplay between WAL, 2PL, and recovery in action
The Setup: T1, T2, T3 Operating on A, B, C
Three transactions running concurrently, each touching different variables.
This creates a complex web of dependencies and potential conflicts that the Transaction Manager must orchestrate.
Scenario 1: All Transactions Commit ✅
✅ Commit Path Coordination
Lock acquisition: In this example, each transaction uses S2PL (i.e., Unlock at COMMIT or ABORT). We can follow a similar microschedule for 2PL as well.
WAL entries: Changes logged sequentially as they occur
Final state: All changes are durable after COMMIT
Scenario 2: Mixed Outcomes - T2 Aborts ❌
❌ Abort Handling
WAL UNDO: Use old values to reverse T3's changes
What's Next? 🎯
The Transaction Manager orchestrates these components to handle concurrent transactions safely.
Up next: See how all the components work together across the full transaction lifecycle!