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.

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

Three transactions all committing successfully

Figure 1. Scenario 1: all three transactions commit. Under Strict 2PL each holds its locks until COMMIT and logs changes in sequence, so every change becomes durable and no transaction ever reads another's uncommitted data.

+ 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

T2 aborts while T1 and T3 commit

Figure 2. Scenario 2: T2 aborts while T1 and T3 commit. Strict 2PL holds exclusive locks until COMMIT or ABORT reaches the WAL, so T1 and T3 never read T2's dirty data and T2's abort does not cascade into them.

The Threat of Cascading Rollbacks

Notice that T1 and T3 are not forced to roll back just because T2 aborted. This is the explicit intent behind the "Strict" in Strict 2PL. By holding exclusive locks until the COMMIT or ABORT hits 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 T2's changes using old values.