Three Transactions, Three Variables
End-to-End Coordination
An end-to-end trace of three concurrent transactions interacting with the logging and locking systems.
The Setup: T1, T2, T3 Operating on A, B, C
Three transactions run concurrently, each targeting a different variable. The Transaction Manager's job? Keep these operations from stepping on each other's toes.
[!NOTE] Theory vs Practice: Bridging the Gap Earlier, we explored Conflict Serializability (drawing acyclic precedence graphs) to mathematically prove a schedule is safe. In production, databases do not run expensive $O(N^2)$ cycle-checking algorithms for every incoming query. Instead, the Transaction Manager enforces Strict Two-Phase Locking (S2PL)—a physical rule that unconditionally guarantees the underlying math remains acyclic.
Scenario 1: All Transactions Commit
+ Commit Path Coordination
Lock acquisition: Each transaction employs Strict Two-Phase Locking (S2PL), unlocking only at COMMIT or ABORT. The same microschedule applies to 2PL.
WAL entries: Changes are logged in sequence as they happen.
Final state: Post-COMMIT, all changes are locked in and durable.
Scenario 2: Mixed Outcomes - T2 Aborts
[!IMPORTANT] The Threat of Cascading Rollbacks Notice that
T1andT3are not forced to roll back just becauseT2aborted. This is the explicit intent behind the "Strict" in Strict 2PL. By holding exclusive locks until theCOMMITorABORThits the WAL, the DB ensures no other transaction can read uncommitted, "dirty" data. This prevents a single aborted transaction from snowballing into a massive, cascading rollback across the system.
− Abort Handling
WAL UNDO: Revert T3's changes using old values.