What Problems Can Occur in Two-Phase Locking?

TL;DR

Two-phase locking always ensures conflict serializability, but it does not guarantee recoverable or cascadeless schedules. Because ordinary 2PL allows locks to be released before commit, transactions may read uncommitted data, causing irrecoverable schedules or cascading rollbacks. Circular lock dependencies can also create deadlocks, while repeated shared-lock grants can leave an exclusive-lock request waiting and cause starvation.

Transcript

Hello friends, welcome to Gate Smashers, In today's video we're going to discuss Problems in 2 PL That is 2 phase locking From competitive exams point of view This topic is very important as question can come on direct theory That does this problem is in 2 PL or not ? or 2 PL remove this problem or not so this type of question is asked very frequen... Read More

Key Insights

• Two-phase locking always ensures conflict serializability because its growing and shrinking phases restrict how transactions acquire and release locks. However, this serializability guarantee does not imply that every resulting schedule is recoverable, cascadeless, deadlock-free, or free from starvation.
• An irrecoverable schedule is possible under ordinary 2PL because lock release is not tied to commit. A writer can unlock an item before committing, allowing another transaction to read the written value, commit, and become impossible to roll back if the writer later fails.
• Cascading rollback is possible when multiple transactions read a value written by an uncommitted transaction. If the writer fails, every transaction that consumed its invalidated value must also be rolled back, provided those dependent transactions have not already committed.
• Cascading rollback degrades performance because one transaction failure can force several dependent transactions to undo their work. Ordinary 2PL therefore does not always produce a cascadeless schedule, even though it still guarantees conflict serializability.
• Deadlock is possible when one transaction holds an exclusive lock on one item and waits for another item held by a second transaction, while the second transaction simultaneously waits for the first item. This circular dependency creates indefinite waiting.
• A transaction's growing phase does not guarantee that every requested lock will be granted immediately. A requested lock must still satisfy compatibility constraints, so a transaction can remain blocked even though it has not begun releasing locks.
• Starvation is possible when an exclusive-lock request waits behind a shared lock while additional compatible shared locks continue to be granted. The exclusive request may wait for a long, finite period because it cannot proceed until all shared locks are released.
• Ordinary 2PL retains four highlighted drawbacks: irrecoverable schedules, cascading rollbacks, deadlocks, and starvation. Variations such as strict, rigorous, and conservative 2PL are identified as later topics for examining which of these problems can be removed.

Questions & Answers

Q: What problems can occur in two-phase locking?

Ordinary two-phase locking can produce irrecoverable schedules, cascading rollbacks, deadlocks, and starvation. It always ensures conflict serializability, but that guarantee does not remove these other problems. Irrecoverability and cascading rollback arise because locks may be released before commit. Deadlocks arise from circular waiting, while starvation can occur when repeated compatible lock grants keep an incompatible request waiting.

Q: Does two-phase locking always ensure serializability?

Two-phase locking always ensures conflict serializability. Its growing phase allows a transaction to acquire locks, while its shrinking phase begins when it starts releasing them. This lock discipline produces serializable execution even when transactions operate concurrently. However, serializability alone does not guarantee recoverability or freedom from cascading rollback, deadlock, and starvation, all of which remain possible under ordinary 2PL.

Q: Why can two-phase locking produce an irrecoverable schedule?

An irrecoverable schedule can occur because ordinary 2PL does not require locks to remain held until commit. A transaction may write an item and release its exclusive lock before committing. Another transaction can then obtain a shared lock, read that value, and commit. If the writer later fails, the reader should be rolled back, but its completed commit prevents that rollback.

Q: How does cascading rollback happen under two-phase locking?

Cascading rollback happens when several transactions read a value written by a transaction that has not committed. After the writer releases its lock, multiple readers can obtain shared locks and consume the changed value. If the writer later fails, its changes must be rolled back. The dependent readers must also be rolled back because the values they read are no longer valid.

Q: Does two-phase locking always produce a cascadeless schedule?

Two-phase locking does not always produce a cascadeless schedule. Ordinary 2PL permits a transaction to release a lock before it commits, so other transactions may read its uncommitted writes. If the writer later fails, those readers may also require rollback. The possibility that one rollback triggers several dependent rollbacks directly demonstrates that cascading schedules can occur under the protocol.

Q: How does deadlock occur in two-phase locking?

Deadlock occurs when transactions wait for locks held by one another. For example, one transaction can hold an exclusive lock on item A and request an exclusive lock on item B, while another transaction holds the lock on B and requests the lock on A. Neither transaction releases its existing lock, so both wait indefinitely in a circular dependency.

Q: Why does the growing phase not prevent deadlock?

The growing phase only means that a transaction is acquiring locks and has not started releasing them. It does not override lock compatibility. If another transaction already holds an incompatible lock on a requested item, the requesting transaction must wait. When transactions hold different locks and request each other's locked items, their growing phases can lead directly to circular waiting and deadlock.

Q: How can starvation occur in two-phase locking?

Starvation can occur when a transaction requests an exclusive lock on an item that currently has a shared lock. The exclusive request must wait. If additional transactions request shared locks before the existing readers release theirs, those compatible shared locks may continue to be granted. The exclusive request consequently waits for a long but finite period until all shared locks are released.

Summary & Key Takeaways

• Two-phase locking divides lock handling into a growing phase and a shrinking phase. Transactions acquire locks during the growing phase and release them during the shrinking phase. This structure always ensures conflict serializability, addressing a limitation of basic shared and exclusive locking, but it does not eliminate every concurrency-control problem.

• Ordinary 2PL does not connect lock release directly to transaction commit. A transaction can therefore release a lock after writing data but before committing. Another transaction may read that uncommitted value and commit first. If the original transaction later fails, the dependent committed transaction cannot be rolled back, making the schedule irrecoverable.

• Two-phase locking can also produce cascading rollbacks, deadlocks, and starvation. Cascading rollback occurs when several transactions read data written by one transaction that later fails. Deadlock results from circular waiting for locks. Starvation occurs when repeated compatible shared-lock requests delay an incompatible exclusive-lock request for a long but finite period.