Concurrency control

Lock-based protocols

One way to ensure serializability is to require the data items be accessed in a mutually exclusive manner One transaction is accessing a data

item, no other transaction can modify that data item.

Common method is “locking”

Locks Lock mode

Shared Locked Lock mode in read operation If a transaction Ti has obtains a shared-mode lock

on item Q, then Ti can read, but cannot write, Q.

Exclusive Locked Lock mode in write operation If a transaction Ti has obtains an exclusive- mode

lock on item Q, then Ti can both read and write Q.

Every transaction request a lock in an appropriate mode on data item Q, depending on types of operations it will perform on Q

When transaction Ti requests a lock mode X on item Q, which is locked by Tj , if the lock mode is in compatible mode, Ti can be granted a lock on Q

Compatible mode can be presented in the following figure

Lock compatibility matrixS X -

S True False True

X False False True

- True True True

Lock compatibility• if A and B represent lock modes.• if Tj hold a lock mode B on item Q• And Ti requests a lock A-mode on item Q

If Ti can be granted a lock on QWe say mode A is compatible with mode B

True mean A Compatible with B

Access data To access data item, transaction must lock

the item first. Lock-S(Q) for share lock Lock-X(Q) for excusive lock Unlock(Q) for unlock data

If data already lock by another transaction in an incompatible mode, the concurrency control manager will not grant the lock until it was released. The Ti is made to wait state.

Two phase locking techniques Technique to control concurrent

execution of transaction Based on “LOCKING”

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

Two-phase locking theorem

If all transactions obey the two-phase locking protocol, then all possible interleaved schedules are serializable.

Eswaran et al., “The notions of consistency and predicate Locks in a Data base system,” CACM 19, No. 11 (November 1976)

The two phase locking protocol allows a transaction to lock a new data

item only if that transaction has not yet unlocked any data item.

The protocol ensures serializability, but not deadlock freedom.

In absence of information concerning the manner in which data items are accessed, the two-phase locking protocol is both necessary and sufficient.

Concurrency and lock

Lost update problem

T1 T2Lock_S(A)

Read_item(A)

A := A – 50

Lock_S(A) Read_item(A)

temp := 0.1*A

A:= A-temp

Lock_X(A)

Wait

Wait

Wait Lock_X(A)

Wait Wait

Wait

T1 T2Read_item(A)

A := A – 50

Read_item(A)

temp := 0.1*A

A:= A-temp

Write_item(A)

Read_item(B)

Write_item(A)

Read_item(B)

B := B + 50

Write_item(B)

B := B + temp Write_item(B

Temporary update problem

T1 T2

- Write_item(R)

Read_item(R) -

-

Rollback

T1 T2

- LOCK_X(R)

Write_item(R)

LOCK_S(R)

Wait

Wait

WaitRollback

UNLOCK(R)

LOCK_S(R)

READ_ITEM(R)

Inconsistency problem

T1 T2

Read_item(A)

SUM = Sum+A

Read_item(B)

SUM = A + B

Read_item(C)

C = C - 10

Write_item(C)

Read_item(A)

A = A + 10

Write_item(A)

COMMIT

Read_item(C)

SUM = SUM + C

T1T1 T2T2

LOCK_S(A)LOCK_S(A)

Read_item(A)

SUM = Sum+A

LOCK_S(B)LOCK_S(B)

Read_item(B)

SUM = A + B

LOCK_X(C)LOCK_X(C)

Read_item(C)

C = C – 10

Write_item(C)

LOCK_S(A)LOCK_S(A)

Read_item(A)

A = A + 10

LOCK_X(A)LOCK_X(A)

Wait

Wait

LOCK_R(C)LOCK_R(C)

Wait

Wait

Dead Lock Two-phase locking protocol can be used to

solve the three basic concurrency problems.

But locking introduce new problems, “DEADLOCKDEADLOCK”

Deadlock is situation in which two or more transactions are in a simultaneous wait state, each of them waiting for one of the others to release a lock before it can be proceed.

How the system detect and break deadlock? Detecting the deadlock involves detecting a cycle in the Wait-

For Graph, which is graph of “who is waiting for whom?” Breaking the dead lock involves choosing one of the

deadlocked transactions as the victim and rolling it back (releasing locks and allowing some other transaction to proceed.

Some system use timeout mechanism and simply assume that a transaction that has done no work for some prescribed period of time is deadlock.

For the victim, some systems automatically restart such a transaction from the beginning, on the assumption that the conditions that caused deadlock will probably not arise again

Some system may send “deadlock victim: exception code back to the application

Deadlock avoidance

Wait-Dei and Wound-Wait No waiting and cautions

waiting Algorithm

Deadlock avoidance Wait-Dei and Wound-Wait Propose in the context of a distributed system, but could be

used in a centralized system as well (1980, J.N. Gray: “Experience with the system R Lock Manager” ) comes in two comes in two versionversion (Wait-die and Wound-wait) work as follows:

Every transaction is timestamped with its start time (which must be unique)

When transaction A requests a lock on a tuple that is already locked by transaction B, then

Wait-Die: A waits if it is older than B; otherwise, it “dies”- that is, A is rolled back and restarted.

Wound-Wait: A waits if it is younger than B; otherwise, it “wounds” B – that is, B is rolled back and restarted.

If transaction has to be restarted, it retains its original timestamp.

Ti older than Tj ( TS(Ti) < TS(Tj)) TS = timestamp, which is a unique identifier assigned to each

transaction. TS based on the order, which transactions are started.

Wait-dieIf ( TS(Ti) < TS(Tj) ) then (Ti older than Tj)

Ti allowed to waitElse

Abort Ti (rollback and restart later)End if

Wound-waitIf ( TS(Ti) < TS(Tj) ) then (Ti older than Tj)

Abort Tj (Ti wound Tj)(rollback and restart later)

Else Ti allowed to wait

End if

No waiting algorithm

If transaction is unable to obtain a lock, it is immediately aborted and then restarted after a certain time delay without checking whether a deadlock will actually occur or not.

Cautions waiting algorithm Caution waiting algorithm was proposed to try to

reduce the number of needlessly abort/restarts.

If Ti tries to lock an item X but X is locked by Tj with conflicting lock.

The cautions waiting rule as follows:If Tj is not blocked (not waiting for some locked item)

then Ti is blocked and allowed to wait;

otherwise Abort Ti

T1 T2

Lock-x(B)Read(B)B:=B-50Write(B)

lock-S(A)

read(A)lock-

s(B)read(B)

lock-X(A)

A = 1000, B= 2000

Dead lock:One transaction already lock and another one try to lock the same data item in incompatible mode, thus in wait state

Locking based protocol

Lock-based protocol is a set of rule to indicate when the transaction may lock or unlock each data item

T1 T2

Lock-x(B)Read(B)B:=B-50Write(B)Unlock(B)

lock-S(A)read(A)

unlock(A)lock-s(B)read(B)unlock(B)

display(A+B)lock-X(A)Read(A)A:=A+50Write(A)Unlock(A)

A = 1000, B= 2000

In this case, result A+B incorrect because T1 unlock B early

Not 2 phase locking Because has unlock during lock

reschedule

T1’: lock-X(B)Read(B)Write(B)B:=B-50Lock-X(A)Unlock(B)Read(A)A:=A+50Write(A)Unlock(A)

T2’: lock-S(A)Read(A)Lock-S(B) Unlock(A)Read(B)Unlock(B)

T1’ and T2’ which are thesame as T1 and T2 schedule but which follow the 2 phase Locking protocol. They can produce dead lock

T2: lock-S(A)Read(A)Unlock(A)Lock-S(B)Read(B)Unlock(B)

T1: lock-X(B)Read(B)B:=B-50Write(B)Unlock(B)Lock-X(A)Read(A)A:=A+50Write(A)Unlock(A)