Strict Two-Phase Locking (S2PL): Safety Over Speed

WHY IT EXISTS Databases need to handle multiple transactions at once without corrupting data. If one transaction fails mid-way, any other transaction that read its partial, uncommitted work would also be invalid. S2PL was created to solve this problem by preventing transactions from seeing uncommitted work, thus avoiding these "cascading aborts" and ensuring a clean, recoverable state.

THE MENTAL MODEL Think of a library's "reserve for in-library use only" policy for a stack of books. A researcher (a transaction) gathers all the books (data rows) they need. They don't put any back until they have finished their entire project and left the library (committed). No one else can even peek at those books until they are officially returned to the shelf, ensuring no one bases their work on research that might be thrown out.

HOW IT WORKS S2PL has two phases, but with a strict rule. First, the growing phase: the transaction acquires all the locks it needs as it executes. Second, the release phase: all acquired locks are released in one atomic action, but only after the transaction has either committed (its changes are permanent) or aborted (its changes are rolled back). There is no "shrinking phase" where locks are gradually released while the transaction is still active. This "hold until the end" rule is what makes it "Strict".

WHEN TO USE IT Use S2PL in systems where strong consistency and recoverability are non-negotiable, which is why it's a common default for transactional databases like those in banking or e-commerce. It guarantees conflict-serializability, meaning the outcome is equivalent to running transactions one by one, and it prevents other transactions from reading uncommitted data.

WHEN NOT TO USE IT Avoid S2PL in high-throughput systems where occasional inconsistencies are acceptable in exchange for better performance. The long lock duration can create bottlenecks and lead to frequent deadlocks, where two or more transactions are stuck waiting for each other. Systems that prioritize availability and speed, like some NoSQL databases, often use more optimistic concurrency control methods instead.

ONE CANONICAL EXAMPLE A transaction to transfer 100 from account A to B. It locks A, subtracts 100. Then it locks B, adds $100. Under S2PL, the locks on both A and B are held until the database confirms the entire transfer is complete and durable (committed). Only then are the locks released for other transactions. If the process fails for any reason before the commit, both locks are held until the rollback is complete.