Locking Side Effects — What Problem Can Locking Introduce? In multi-user database systems, which issue can be directly caused by locking when concurrent transactions compete for resources?

Introduction / Context:
Locks protect data consistency, but they can also introduce contention problems. One classic issue is deadlock, where two or more transactions wait on each other’s locks and none can proceed without intervention.

Given Data / Assumptions:

• Standard two-phase locking behavior is assumed.
• Transactions acquire locks to read/update rows or pages.
• We must identify a problem that locking itself can cause.

Concept / Approach:
Deadlock occurs when circular wait conditions arise. For example, T1 holds lock A and requests lock B; T2 holds lock B and requests lock A. Since each waits for the other, progress halts until the DBMS detects the deadlock and aborts one transaction. Erroneous updates are prevented—not caused—by correct locking. Versioning is an alternative concurrency strategy used by some engines to reduce blocking; it is not caused by locking.

Step-by-Step Solution:
Analyze each option relative to locking.Recognize circular waits as a direct by-product of locks on interdependent resources.Identify deadlock as the locking-induced issue.Select “Deadlock.”

Verification / Alternative check:
DBMS engines include deadlock detection (wait-for graphs) and resolution (victim selection and rollback). This confirms deadlock is a known locking side effect.

Why Other Options Are Wrong:

• Erroneous updates: Locking prevents lost updates, it does not create them.
• Versioning: A concurrency alternative like snapshot isolation, not a locking-induced problem.
• All of the above: Incorrect because only deadlock fits.
• Phantom reads under snapshot: Phantoms relate to isolation semantics and indexing, not a problem caused by locking.

Common Pitfalls:
Blaming locking for performance symptoms broadly; the specific issue attributable to locking mechanics here is deadlock.

Final Answer:
Deadlock