Chapter 9 Concurrency Control 9.1 Lock-Based Protocols 9.2 Multiple Granularity 9.3 Deadlock Handling 9.4 Insert and Delete Operations

Chapter 9 Concurrency Control

9.1 Lock-Based Protocols 9.2 Multiple Granularity 9.3 Deadlock Handling 9.4 Insert and Delete Operations

9.1 Lock-Based Protocols

One way to ensure serializability is to require that data items be accessed in a mutually exclusive manner.(lock) 1. Shared: if a transaction Ti has obtained a shared-mode lock on item Q, then Ti can read, but cannot write Q.

2. Exculsive: if a transaction Ti has obtained an exclusive-mode lock on item Q, then Ti can both read and write Q.

S X

S true false

X false false

Compatibility function:

9.1 Lock-Based Protocols T1

lock-X(B)

read(B)B:=B-50write(B)unlock(B)

lock-X(A)

read(A)A:=A+50write(A)unlock(A)

T2

lock-S(A)

read(A)

unlock(A)

lock-S(B)

read(B)

unlock(B)

display(A+B)

concurrency-control manager

grant-X(B,T1)

grant-S(A,T2)

grant-S(B,T2)

grant-X(A,T1)

lock-X(B)

read(B)

B:=B-50

write(B)

unlock(B)

lock-X(A)

read(A)

A:=A+50

write(A)

unlock(A)

T1:

lock-S(A)

read(A)

unlock(A)

lock-S(B)

read(B)

unlock(B)

display(A+B)

T2:


lock-X(B)

read(B)

B:=B-50

write(B)

lock-X(A)

read(A)

A:=A+50

write(A)

unlock(B) unlock(A)

T3: lock-S(A)

read(A)

lock-S(B)

read(B)

unlock(A) unlock(B)

display(A+B)

T4: T3

lock-X(B)

read(B)

B:=B-50

write(B)

lock-X(A)

T4

lock-S(A)

read(A)

lock-S(B)

deadlock


When a transaction requests a lock on a data item in a particular node, and no other transaction has a lock on the same data item in a conflicting mode, the lock can be granted.

T1

lock-X(A)

wait

wait

wait

wait

….

T2

lock-S(A)

A:=A+50

unlock(A)

T3

lock-S(A)

A:=A+10

unlock(A)

T4

lock-S(A)

A:=A-20

unlock(A)

Ti

lock-S(A)

……

…

starvation

One protocol that ensures serializability is the two-phase locking protocol. This protocol requires that each transaction issue lock and unlock requests in two phases:

① Growing phase. A transaction may obtain locks, but may not release any lock.

② Shrinking phase. A transaction may release locks, but may not obtain any new locks.

9.1.3 The Two-Phase Locking Protocol


T1

lock-S(B)

read(B)

lock-X(A)

A:=B+1

write(A)

unlock(B)

unlock(A)

T2

lock-S(A)

wait

wait

wait

wait

lock-S(A)

read(A)

lock-X(B)

B:=A+1

write(B)

unlock(B)

unlock(A)

T3

lock-S(B)

read(B)

unlock(B)

lock-X(A)

A:=B+1

write(A)

unlock(A)

T4

lock-S(A)

wait

wait

wait

lock-S(A)

read(A)

unlock(A)

lock-X(B)

B:=A+1

write(B)

unlock(B)

growing phase

shrinking phase

lock point

T3 、 T4 Serializable

Not two phase

T1 、 T2 Serializabletwo phase

The two-phase

locking protocol ensures conflict

serializability

9.1.3 The Two-Phase Locking Protocol T3

lock-X(B)

read(B)

B:=B-50

write(B)

lock-X(A)

T4

lock-S(A)

read(A)

lock-S(B)

deadlock

T3 、 T4 two phase

Two-phase locking does not ensure

freedom from

deadlock.

T5

lock-X(A)

read(A)

lock-S(B)

read(B)

write(A)

unlock(A)

T6

lock-S(A)

read(A)

write(A)

unlock(A)

T7

lock-S(A)

read(A)

T5 、 T6 、 T7

two phase

Cascading rollback may occur under two-

phase locking.

Strict two-phase locking protocol: This protocol requires not only that locking be two phase, but also that all exclusive-mode locks taken by a transaction be held until that transaction commits.

Rigorous two-phase locking protocol: This protocol requires that all locks be held until the transaction commits.


read(a1);

read(a2);

…

read(an);

write(a1);

T8:

read(a1);

read(a2);

display(A+B)

T9:

T8

lock-S(a1)

lock-S(a2)

lock-S(a3) lock-S(a4)

lock-S(an) upgrade(a1)

T9

lock-S(a1)

lock-S(a2)

unlock(a1)

unlock(a2)

lock conversion


Upgrade:share to exclusive modeUpgrading can take place in only the growing phase

Downgrade:exclusive to share modedowngrading can take place in only the shrinking phase

When a transaction Ti issues a read(Q) operation, the system issues a lock-S(Q) instruction followed by the read(Q) instruction.

When Ti issues a write (Q) operation, the system checks to see whether Ti already holds a shared lock on Q. if it does, then the system issues an up-grade (Q) instruction, followed by the write (Q) instruction. Otherwise, the system issues a lock-X (Q) instruction, followed by the write (Q) instruction.

All locks obtained by a transaction are unlocked after that transaction commits or aborts.


Tree protocol: the only lock instruction allowed is lock-X. each transaction Ti can lock a data item at most once, and must observe the following rules:

① The first lock by Ti may be on any data item.

② Subsequently, a data item Q can be locked by Ti

only if the parent of Q is currently locked by Ti.

③ Data items may be unlocked at any time.

④ A data item that has been locked and unlocked by Ti cannot subsequently be relocked by Ti.

9.1.4 Graph-Based Protocols

Lock and unlock instructions:T10: lock-X(B); lock-X(E); lock-X(D);

unlock(B); unlock(E); lock-X(G);

unlock(D); unlock(G);

T11: lock-X(D); lock-X(H); unlock(D);

unlock(H);

T12: lock-X(B); lock-X(E); unlock(E);

unlock(B);

T13: lock-X(D); lock-X(H); unlock(D);

unlock(H);


A

B C

FE

I

D

G H

J

9.1.4 Graph-Based Protocols T10

lock-X(B)

lock-X(E)

lock-X(D)

unlock(B)

unlock(E)

lock-X(G)

unlock(D)

unlock(G)

T11

lock-X(D)

lock-X(H)

unlock(D)

unlock(H)

T12

lock-X(B)

lock-X(E)

unlock(E)

unlock(B)

T13

lock-X(D)

lock-X(H)

unlock(D)

unlock(H)

A

B C

FE

I

D

G H

J

Tree protocol ensures conflict serializability and freedom from deadlock

Tree protocoldoes not ensure recoverability and cascadelessness.

Advantages: ① unlike two-phase locking, it is deadlock-free, so no rollbacks are required.unlocking may occur earlier. ② Earlier unlocking may lead to shorter waiting times, and to an increase in concurrency.Disadvantages: ① in some cases, a transaction may have to lock data items that it does not access. ② Without prior knowledge of what data items will need to be locked, transactions will have to lock the root of the tree, and that can reduce concurrency greatly.


A method for determining the serializability order is to select an ordering among transactions in advance.(timestamp-ordering scheme)Timestamps: with each transaction Ti in the system, we associate a unique fixed timestamp, denoted by TS(Ti). This timestamp is assigned by the database system before the transaction Ti starts execution. If a transaction Ti has been assigned timestamp TS(Ti), and a new transaction Tj enters the system, then TS(Ti)< TS(Tj). There are two simple methods for implementing this scheme:

① Use the value of the system clock as the timestamp; that is, a transaction’s timestamp is equal to the value of the clock when the transaction enters the system.

② Use a logical counter that is incremented after a new timestamp has been assigned; that is, a transaction’s timestamp is equal to the value of the counter when the transaction enters the system.

9.2 Timestamp-Based Protocols

Timestamp-ordering protocol:

1.Suppose that transaction Ti issues read(Q). a. If TS(Ti)<W-timestamp(Q), then Ti needs to read a value of Q

that was already overwritten. Hence, the read operation is rejected, and Ti is rolled back.

b. If TS(Ti)>=W-timestamp(Q) then the read operation is executed, and R-timestamp(Q) is set to the maximum of R-timestamp(Q) and TS(Ti).


2.Suppose that transaction Ti issues write(Q).

a. If TS(Ti)<R-timestamp(Q), then the value of that Ti is producing was needed previously, and the system assumed that value would never be produced. Hence, the system rejects the write operation and rolls Ti back.

b. If TS(Ti)<W-timestamp(Q) then Ti is attempting to write an obsolete value of Q. hence, the system rejects this write operation and rolls Ti back.

c. Otherwise, the system executes the write operation and sets W -timestamp(Q) to TS(Ti)



read(B);

read(A);

display(A+B);

T14:

read(B);

B:=B-50;

write(B);

read(A);

A:=A+50;

write(A);

display(A+B);

T15:

T14

read(B)

read(A)

display(A+B)

T15

read(B)

B:=B-50

write(B)

read(A)

A:=A+50

write(A)

display(A+B)

R-timestamp(B)= TS(T15)

W-timestamp(B)= TS(T15)

TS(T14)< TS(T15)

R-timestamp(A)= TS(T15)

9.4 Multiple Granularity

IS IX S SIX X

IS true true true true false

IX true true false false false

S true false true false false

SIX true false false false false

X false false false false false

A system is in a deadlock state if there exists a set of transactions such that every transaction in the set is waiting for another transaction in the set.

There two principal methods for dealing with the deadlock problem:

① deadlock prevention

② deadlock detection&deadlock recovery

9.4 Deadlock Handling

There are two approaches to deadlock prevention:① one approach ensures that no cyclic waits can occur by ordering the requests for locks, or requiring all locks to be acquired together.Disadvantages: a. It is often hard to predict, before the transaction begins,what data items need to be locked. b. Data-item utilization may be very low.

② the other approach is closer to deadlock recovery, an performs transaction rollback instead of waiting for a lock, whenever the wait could potentially result in a deadlock.

9.4.1 Deadlock Prevention

1.The wait-die scheme is a nonpreemptive technique. When transaction Ti requests a data item currently held by Tj, Ti is allowed to wait only if it has a timestamp smaller than that of Tj(that is, Ti is older than Tj). Otherwise, Ti is rolled back(dies).


timestamp T22 T23 T24

5 10 15

T22

lock-S(A)

wait

T23

lock-X(A)

T24

lock-X(A)

rollback

T3

lock-X(B)

read(B)

write(B)

lock-X(A)

T4

lock-S(A)

read(A)

lock-S(B)

Timestamp:T3<T4

T4 rollback

2. The wound-wait scheme is a primitive technique. It is a counterpart to the wait-die scheme. When transaction Ti requests a data item currently held by Tj, Ti is allowed to wait only if it has a timestamp larger than that of Tj(that is, Ti is younger than Tj). Otherwise, Tj is rolled back(Tj is wounded by Ti).


timestamp T22 T23 T24

5 10 15

T22

lock-S(A)

T23

lock-X(A)

rollback

T24

lock-X(A)

wait

T3

lock-X(B)

read(B)

write(B)

lock-X(A)

T4

lock-S(A)

read(A)

lock-S(B)

Timestamp:T3<T4

T4 rollback

Similarity: both the wound-wait and the wait-die schemes avoid starvation.

Difference: operation ① In the wait-die scheme, the older the transaction gets, the more it

tends to wait. By contrast, in the wound-wait scheme, an older transaction never waits for a younger transaction.

② In the wait-die scheme, if a transaction Ti dies and is rolled back because it requested a data item held by transaction Tj, the Ti may reissue the same sequence of requests when it is restarted. If the data item is still held by Tj, then Ti will die again. Thus, Ti may die several times before acquiring the needed data item.contrast this series of events with what happens in the wound-wait scheme. There may be fewer rollbacks in the wound-wait scheme.


Lock timeouts: a transaction that has requested a lock waits for at most a specified amount of time. If the lock has not been granted within that time, the transaction is said to timeout ,and it rolls itself back and restarts. If there was in fact a deadlock, one or more transactions involved in the deadlock will time out and roll back, allowing the others to proceed.

9.4.2 Timeout-Based Scheme

Deadlock Detection:

wait-for graph:G=(V,E) V:is a set of vertices E:is a set of edges Ti→Tj: transaction Ti is waiting for transaction Tj to release a data item that it needs.

9.4.3 Deadlock Detection and Recovery

T25

T27

T28T26 T28

T25

T27

T26

Transaction T28 is requesting an

item held by T27. Deadlock: contains a cycle

Recovery from Deadlock: roll back ①selection of a victim: Given a set of deadlocked transactions, we must determine which transaction to rollback to break the deadlock.(minimum cost)

② Rollback: Once we have decided that a particular transaction must be rolled back, we must determine how far this transaction should be rolled back.(total rollback, partial rollback)

③ Starvation: We must ensure that transaction can be picked as a victim only a finite number of times.(include the number of rollbacks in the cost factor)

9.4.3 Deadlock Detection and Recovery

Exercises:

Documents

Chapter 9 Concurrency Control 9.1 Lock-Based Protocols 9.2 Multiple Granularity 9.3 Deadlock Handling 9.4 Insert and Delete Operations