Why Database Transactions Use Two-Phase Locking

In this episode, Lucas and Luna dig into two-phase locking—the protocol that keeps database transactions from colliding. They use the example of a bank transfer, where a debit and a credit must happen atomically, to show why locking is more than just 'preventing overwrites.' The conversation walks through the two phases: growing, where locks are only acquired, and shrinking, where locks are only released. They explain why two-phase locking guarantees serializability, and why that guarantee comes at a cost—lock contention, deadlocks, and cascading aborts. They also touch on how modern databases like PostgreSQL and MySQL implement it, and why some systems opt for weaker isolation levels to get more throughput. A practical analogy about a shared hotel room helps ground the concept, and the hosts compare two-phase locking to optimistic concurrency control, familiar from the earlier episode on snapshots. No previous database knowledge needed—just a curious mind.

#TwoPhaseLocking #DatabaseTransactions #Serializability #ConcurrencyControl #LockingProtocol #ACID #PostgreSQL #MySQL #DatabaseInternals #DataEngineering #SQL #NoSQL #TransactionIsolation #Deadlock #DatabasePerformance #TechPodcast #FexingoBusiness #BusinessPodcast

Keep every episode free: buymeacoffee.com/fexingo