Transactions and Locking

Why this module exists

Atomicity and isolation are not optional. Without them, your database returns corrupt answers under concurrency. We focus on strict two-phase locking (2PL) with deadlock handling.

1) Two-phase locking (2PL)

2PL requires that:

• Locks are acquired before use
• Locks are released only at commit/abort

Strict 2PL (release only at commit) prevents dirty reads and guarantees serializability.

2) Lock modes

We use shared (S) and exclusive (X) locks:

• S locks are compatible with S
• X locks are exclusive

Compatibility is a matrix, not a guess.

3) Deadlocks

When transactions wait on each other, progress stops. You must detect cycles or enforce ordering. We will implement a wait-for graph detection strategy.

What you will build

• A lock manager that grants or queues lock requests and detects deadlocks.

Key takeaways

• Isolation is enforced by locking rules.
• Compatibility and ordering are explicit.
• Deadlock handling is part of correctness, not a feature.