Understanding Two-Phase Locking in Databases

· 6 min read

Hey everyone, it’s alanturrr1703 back again with another blog! 😁 Today, we’re diving into the concept of Two-Phase Locking (2PL)—a fundamental technique used to maintain concurrency control in databases. If you’ve been curious about how databases handle multiple transactions while keeping everything consistent, this is for you. Let’s break it down!

What is Two-Phase Locking?

Two-Phase Locking (2PL) is a protocol used by database management systems to ensure serializability, which is the highest level of transaction isolation. This means it allows transactions to run in such a way that their outcomes are equivalent to executing them one by one, even when they actually run concurrently.

In simple terms, 2PL is all about controlling when and how transactions acquire and release locks on data. A lock is like a reservation on a data item (a row or a table), preventing other transactions from modifying it at the same time.

2PL divides the life of a transaction into two distinct phases:

  1. Growing Phase: The transaction can acquire locks but cannot release any.
  2. Shrinking Phase: The transaction releases locks but cannot acquire any more.

Let’s look at these phases more closely.

The Two Phases of 2PL

1. Growing Phase

In the growing phase, the transaction starts by acquiring all the locks it needs. A transaction can lock different data items (e.g., rows or tables) for reading (shared lock) or writing (exclusive lock). During this phase, the transaction can continue requesting new locks as it encounters data it needs to read or modify.

However, it cannot release any of these locks during the growing phase. This ensures that the transaction has complete control over the data it needs before it starts releasing locks.

2. Shrinking Phase

Once the transaction starts releasing locks, it enters the shrinking phase. During this phase, no new locks can be acquired; the transaction only releases the locks it previously held.

By following this strict order—first acquiring locks, then releasing them—a transaction prevents other transactions from accessing inconsistent or partially updated data. This helps maintain data integrity.

Example of Two-Phase Locking:

Let’s consider an example of two transactions working with a simple banking system:

  • Transaction 1: Transfers ₹500 from Account A to Account B.
  • Transaction 2: Reads the balance of Account A and Account B.

Here’s how Two-Phase Locking works in this case:

  1. Growing Phase:

    • Transaction 1 locks Account A and Account B for writing (exclusive lock).
    • Transaction 2 tries to read Account A but has to wait because Transaction 1 has a write lock on it.

  2. Shrinking Phase:

    • Transaction 1 finishes the transfer and releases the locks on Account A and Account B.
    • Now Transaction 2 can acquire a read lock and read the updated balances.

Thanks to 2PL, Transaction 2 will never read inconsistent or incomplete data, ensuring serializability.

Types of Two-Phase Locking

There are different versions of Two-Phase Locking that enhance its flexibility and performance:

1. Strict Two-Phase Locking (Strict 2PL)

In Strict 2PL, a transaction holds all its exclusive locks (for writing) until the transaction commits or aborts. This means no other transaction can read or modify any data item that’s being written by the current transaction until the transaction completes.

Pros:

  • It prevents dirty reads, ensuring that other transactions never see uncommitted data.
  • Ensures strict serializability.

Cons:

  • Can lead to higher contention as transactions may need to wait longer to access locked resources.

2. Rigorous Two-Phase Locking

In Rigorous 2PL, all locks—both shared (read) and exclusive (write)—are held until the transaction commits. This is a slightly stricter version of Strict 2PL because even shared locks aren’t released until the transaction is done.

Pros:

  • This makes it even easier to reason about transaction order since no locks are released early.

Cons:

  • It can cause more waiting for resources since locks are held longer than necessary.

3. Conservative Two-Phase Locking (Static 2PL)

In Conservative 2PL, the transaction tries to acquire all the locks it will ever need before it starts. If the transaction can’t acquire all the locks at once, it waits and tries again.

Pros:

  • Completely avoids deadlocks because the transaction ensures it has all the resources it needs before proceeding.

Cons:

  • It can be inefficient and harder to implement because transactions need to know all the data they will access upfront, which isn’t always possible.

How 2PL Prevents Common Concurrency Issues

By following the two-phase protocol, Two-Phase Locking prevents several common concurrency problems:

1. Dirty Reads:

When a transaction reads uncommitted data from another transaction. 2PL avoids this by ensuring that locks are held until a transaction commits, so no other transaction can read partially completed data.

2. Non-Repeatable Reads:

When a transaction reads the same data twice and gets different values each time because another transaction has modified the data in between. With 2PL, locks prevent this from happening since the first transaction holds a lock on the data until it finishes.

3. Phantom Reads:

When a transaction reads a range of data, but another transaction inserts new rows into that range, causing inconsistent results. By locking data ranges (in advanced implementations like index-range locking), 2PL can prevent this issue.

4. Write Skew:

As we discussed in the previous blog, Write Skew happens when concurrent transactions make decisions based on the same data, leading to conflicting results. With 2PL, transactions must acquire locks on data before modifying it, which avoids the skew.

Deadlocks in 2PL

While 2PL is great for maintaining consistency, it comes with a risk: deadlocks. Deadlocks occur when two or more transactions are waiting for each other’s locks, and none of them can proceed. It’s like a “traffic jam” in the database.

Example:

  • Transaction 1 locks Account A and tries to lock Account B.
  • Transaction 2 locks Account B and tries to lock Account A.

Now both transactions are waiting for each other’s lock, and neither can move forward.

How to Handle Deadlocks:

  • Deadlock Detection: Some systems periodically check for deadlocks and terminate one of the transactions to resolve the situation.
  • Timeouts: Some databases set time limits for how long a transaction can wait for a lock. If it exceeds the limit, the transaction is aborted and retried.
  • Conservative 2PL: As mentioned earlier, this approach avoids deadlocks entirely by ensuring that a transaction acquires all required locks at once.

Wrapping It Up

Two-Phase Locking (2PL) is a critical protocol for ensuring serializability in databases by controlling how and when transactions acquire and release locks. While it helps prevent common concurrency issues like dirty reads and phantom writes, it comes with the trade-off of potential deadlocks and performance bottlenecks.

If you need strict data consistency and can afford some transaction delay, Strict 2PL is the way to go. For performance-sensitive applications, you might explore other concurrency control mechanisms alongside 2PL to find the right balance.

That’s all for today! I hope this helped clarify Two-Phase Locking and how it keeps your database transactions safe and sound. Until next time! 🚀