Concurrency Control II

Instructor: Meng-Fen Chiang

WEEK 11.2

Slides adapted from “Database System Concepts” Seventh Edition, Miao Qiao
RECAP: Two-Phase Locking Protocol

A protocol which ensures conflict-serializable

schedules

1. Expanding (growing) phase: Ph

Locks

e1
as
• Transaction may obtain locks e2

as
lock points

Ph
• Transaction may not release locks

2. Shrinking phase: Time

• Transaction may release locks
• Transaction may not obtain locks

2
RECAP: Variations of Two-Phase Locking

• Basic 2PL (see previous slides)

• Conservative (static) 2PL: Requires a transaction to

lock all the items it accesses before the transaction
begins (Predeclare read-set and write-set)

• Strict 2PL: Transaction does not release exclusive

locks until after it commits or aborts

• Rigorous 2PL: Transaction does not release any locks

until after it commits or aborts

3
OUTLINE
Part 7: Transaction Management
• Chap17: Transactions
• Chap18: Concurrency
• Binary Locks
• Shared/Exclusive Locks
• Two-phase Locks
• Update Locks
• Increment Locks
• Locks with Multiple Granularity
• Locking scheduler
• Starvation and deadlock
• Chap 19: Recovery

5
Using Locks for Concurrency Control in Indexes

• Insertion: When new data item is inserted, it cannot be accessed until after the
operation is completed
• Deletion operation on the existing data item: write lock must be obtained before
deletion

Phantom revisited
• Phantom can occur when a new record being inserted satisfies a condition that a set
of records accessed by another transaction must satisfy
• The record that causes conflict is not recognized by concurrency control protocol

9
OUTLINE

Part 7: Transaction Management

• Chap17: Transactions
• Chap18: Concurrency
• Binary Locks
• Shared/Exclusive Locks
• Two-phase Locks
• Update Locks
• Increment Locks
• Locks with Multiple Granularity
• Locking scheduler
• Starvation and deadlock
• Chap 19: Recovery

12
Starvation and Deadlock

• Starvation: a transaction cannot proceed for an indefinite period of time while other
transactions continue normally.

• Solution: first-come-first-serve queue for each lock (waiting list)

• Deadlock: a set 𝑆 of ≥ 2 transactions has a deadlock if each transaction 𝑇 in 𝑆 is

waiting for some item that is locked by another transaction in 𝑆.

13
Deadlock Detection

• Detect deadlock by timeout. If the system waits for a transaction T longer than a
predefined threshold, abort T and then restart T. Drawback: no perfect time limit.
• Detect deadlock with a wait-for graph. A set S of transactions has a deadlock if there
is a cycle in the wait-for graph of S.
• An edge from 𝑇! to 𝑇" if 𝑇! is waiting for a lock currently hold by 𝑇" .

14
Victim selection: Abort one transaction T in case of a deadlock and restart T .
Deadlock Detection

Wait-For Graph after Step (7) Wait-For Graph after Step (8) 15
Deadlock Detection

• The system is in a deadlock state if and only if the wait-for graph has a cycle.
• Invoke a deadlock-detection algorithm periodically to look for cycles.

T18 T20 T18 T20

T17 T17

T19 T19

(a) Wait-for graph wo a cycle (b) Wait-for graph with a cycle

16
Deadlock Recovery

When a deadlock is detected :

• Some transactions will have to be rolled back (made a victim) to break the deadlock cycle.
• Select that transaction as a victim that will incur a minimum cost
• Rollback -- determine how far to roll back the transaction
• Total rollback: Abort the transaction and then restart it.
• Partial rollback: Roll back victim transactions only as far as necessary to release locks that another
transaction in the cycle is waiting for

Starvation can happen (why?)

• One solution: the oldest transaction in the deadlock set is never chosen as a victim

17
Exercise

Question: Consider the following schedule S of transactions T1 and T2:

(A) S is serializable only as T1, T2
(B) S is serializable only as T2, T1
(C) S is serializable both as T1, T2 and T2, T1
(D) S is serializable either as T1 or as T2
(E) None of these

18
Deadlock & Starvation Prevention Protocols

Transaction Timestamp
• Assign, for each transaction 𝑇, a unique identifier 𝑇𝑆(𝑇) related to the starting time
of the transaction (a smaller 𝑇𝑆(𝑇) means an older transaction).

There are two protocols to prevent both deadlock and starvation.

Let 𝑇 be a transaction that is requesting a lock that is currently held by transaction 𝑈.

• Wait-die: If 𝑇𝑆(𝑇) < 𝑇𝑆(𝑈), let 𝑇 wait for the lock; otherwise, abort 𝑇.
• Would-wait: If 𝑇𝑆(𝑇) < 𝑇𝑆(𝑈), abort 𝑈; otherwise, let 𝑇 to wait for the lock.

19
Deadlock & Starvation Prevention Protocols

1. wait-die scheme: non-preemptive

• Older transaction may wait for younger one to release data item.
• Younger transactions never wait for older ones; they are rolled back instead.
• A transaction may die several times before acquiring a lock

2. wound-wait scheme: preemptive

• Older transaction wounds (forces rollback) of younger transaction instead of waiting for it.
• Younger transactions may wait for older ones.
• Fewer rollbacks than wait-die scheme.

20
Deadlock & Starvation Prevention Protocols

All transactions will eventually compete:

• Both wait-die and wound-wait schemes kills young transactions in a competition of resources.

• In both schemes, a rolled back transactions is restarted with its original timestamp.
• Ensures that older transactions have precedence over newer ones, and starvation is thus
avoided.

• The aborted transaction will be resumed with the original timestamp, so young transactions
that are killed will eventually be old.

21
Deadlock & Starvation Prevention Protocols

3. Timeout-Based Schemes:
• A transaction waits for a lock only for a specified amount of time. After that, the
wait times out and the transaction is rolled back.
• Ensures that deadlocks get resolved by timeout if they occur
• Simple to implement
• But may roll back transaction unnecessarily in absence of deadlock
• Difficult to determine good value of the timeout interval.
• Starvation is also possible

22
SUMMARY: Deadlock Prevention Protocols

• Deadlock is like a traffic jam in a database where transactions are stopped because they are
waiting for each other to move.
• To overcome this, we need to design transactions carefully, use smart strategies to detect
deadlocks, and have a plan to untangle deadlocks so as to avoid traffic jams.

23
SUMMARY
Part 7: Transaction Management
• Chap17: Transactions
• Chap18: Concurrency
• Binary Locks
• Shared/Exclusive Locks
• Two-phase Locks
• Update Locks
• Increment Locks
• Locks with Multiple Granularity
• Locking scheduler
• Starvation and deadlock
• Chap 19: Recovery

Source: https://helloworld957536278.wordpress.com/2021/09/06/understand-deadlock-in-
24
postgres-and-how-to-fix-it/