Two-Phase Locking and serializability

What's really being asked

The interviewer checks whether you understand a concurrency-control protocol that guarantees serializability, and whether you can keep it distinct from two-phase commit.

The full answer

Two-Phase Locking governs the order in which a transaction acquires and releases locks. It has two phases. In the growing phase the transaction may acquire locks but may not release any. The moment it releases its first lock it enters the shrinking phase, during which it may release locks but may never acquire a new one. This single rule, no acquisition after any release, ensures that the resulting schedule is conflict-serializable, meaning equivalent to some serial order of the transactions. A common refinement is strict 2PL, which holds all exclusive locks until the transaction commits or aborts; this additionally prevents cascading aborts and dirty reads, at the cost of holding locks longer. 2PL can itself cause deadlocks, since transactions may wait on each other's locks, so it pairs with deadlock detection.

The mistakes people make

Confusing 2PL with two-phase commit, an unrelated protocol for atomic commit across distributed nodes. Thinking 2PL prevents deadlocks; it does not, it can cause them. Believing basic 2PL alone prevents cascading aborts, which is actually a property of strict 2PL.

What usually comes next

How does strict 2PL differ from basic 2PL? Why does 2PL risk deadlock? What is conflict-serializability? How does 2PL compare with MVCC-based approaches?

A concrete example

A transfer locks both accounts during its growing phase, performs the debit and credit, and only then, in its shrinking phase, releases the locks. Because it never grabs a new lock after releasing one, no other transaction can interleave in a way that produces a non-serializable result.