1. Lecture 3 Concurrency control techniques
Database Management
Lecture 3
Concurrency control techniques

2. Objectives Dealing with Deadlock Lock based concurrency control
2PL protocol
Lock management
Dealing with Deadlock
Multiple Granularity Locking

3. Database Concurrency Control
Purpose of Concurrency Control
To enforce Isolation (through mutual exclusion) among conflicting transactions.
To preserve database consistency through consistency preserving execution of transactions (serializable schedules).
Ensure recoverability only recoverable schedules should be allowed.

4. Concurrency Control Techniques
Chapter Name
September 98
Concurrency Control Techniques
There are 3 concurrency control techniques:
Locking
Timestamping
Optimistic
Locking and Timestamping both are conservative (pessimistic) approaches.
Optimistic methods assume conflicts arerare and only check for conflicts at commit. 31

5. Lock based concurrency control
A locking protocol is a set of rules to be followed by each transaction to ensure that all transactions executed in some serial order.
One of the methods to ensure serialazable schedules is to lock items accessed by transactions

6. Binary locking scheme
Lock is an operation which secures (a) permission to Read or (b) permission to Write a data item for a transaction.
Unlock is an operation which removes these permissions from the data item.
Lock and Unlock are Atomic operations.

7. Shared/Exclusive locking scheme
Binary locking is too restrictive and reduces concurrency
Shared mode: shared lock (X). More than one transaction can apply share lock on X for reading its value but no write lock can be applied on X by any other transaction.
Exclusive mode: Write lock (X). Only one write lock on X can exist at any time and no shared lock can be applied by any other transaction on X.

8. Lock based concurrency control
Lock Manager: Managing locks on data items.
Lock table: Lock manager uses it to store the identify of transaction locking a data item, the data item, lock mode and pointer to the next data item locked. One simple way to implement a lock table is through linked list.

9. Locking - Basic Rules
Chapter Name
September 98
Generally, a transaction must claim a read (shared) lock on a data item before it can read it.
read lock an item, a transaction can read but not update the item.
reads cannot conflict, so transactions can, simultaneously, hold a read lock on the same item. 33

10. Locking - Basic Rules
Generally, a transaction must claim a write (exclusive) lock on a data item before it can write to it.
write lock an item, a transaction can both read and update the item.
a write lock gives a transaction exclusive access to that item.

11. Locking - Basic Rules
any transaction that needs access to a data item must first request a read or write lock on the item.
if the item is not already locked by another transaction, the lock is granted.

12. Locking - Basic Rules
if the item is already locked the DBMS determines the type of lock.
Lock
Read
(requested)
Write
None
Grant
Read (held)
Wait
Write (held)
a transaction holds a lock until it explicity releases it, or the transaction commits or aborts.

13. If a transaction locks an item, it must later unlock the item.
Locking - Basic Rules
Chapter Name
September 98
A transaction can only read or write an item if it has previously requested, and been granted a lock on that item and, it hasn’t released the lock.
If a transaction locks an item, it must later unlock the item. 34

14. convert write-lock (X) to read-lock (X)
Lock conversion
Lock upgrade:
existing read lock to write lock
if Ti has a read-lock (X) and Tj has no read-lock (X) (i j)
then
convert read-lock (X) to write-lock (X
else
force Ti to wait until Tj unlocks X
Lock downgrade:
existing write lock to read lock
if Ti has a write-lock (X) then
convert write-lock (X) to read-lock (X)

15. Locking
Does use of locks guarantee serializability on its own?

16. Incorrect locking schedule
Time T9
T10
bal x
baly
220
200
100
unlock( by)
wait 15
unlock( bx) 10
begin_trans
bx= bx +100 4
commit(T10)
write( by)
by = by *1.1
read( by)
write_lock( by)
write( bx)
bx = bx * 1.1
read( bx)
write_lock( bx)
commit(T9) 20 19
340 18
by = by - 100 17
440 16 14 13
400 12 11 9 8 7
unlock(bx) 6
write(bx) 5 3
write_lock(bx) 2 1

17. Incorrect locking schedule
If at start, balx = 100, baly = 400, the serial result should be:
if T9 executes before T10 then
balx = ( ) * 1.1 = 220
baly = ( ) * 1.1 = 330 or
if T10 executes before T9 then
balx = (100 * 1.1) = 210
baly = (400 * 1.1) – 100 = 340
However,
T10 uses balx from T9 result balx = 220
T9 uses baly from T10 result baly = 340
Schedule S is not a serializable schedule.

18. Incorrect Locking Schedule
Chapter Name
September 98
Simply following the locking rules does not necessarily result in a correct schedule.
The problem is that transactions release locks too soon, resulting in loss of total isolation and atomicity.
To guarantee serializability, an additional protocol is required concerning the positioning of lock and unlock operations in every transaction. The best known protocol is Two-Phase Locking (2PL). 37

19. 2 Phase Locking protocol
A transaction is said to follow 2PL protocol if all locks precede the first unlock
2 phases:
Expanding -A transaction applies locks (read or write) on desired data items one at a time.
Shrinking - A transaction unlocks its locked data items one at a time.
Requirement: during locking phase unlocking phase must not start and during unlocking phase locking phase must not begin.

20. Corrected Schedule Time T1 T2 balx baly 220 200 100 unlock( by) 15
unlock( bx) 10
begin_trans
bx= bx +100 4
commit(T10)
write( by)
by = by *1.1
read( by)
write_lock( by)
write( bx)
bx = bx * 1.1
read( bx)
wait
write_lock( bx)
commit(T9) 20 19 18
by = by - 100 17 16
300 14 13
400 12 11 9 8 7
unlock(bx) 6
write(bx) 5 3
write_lock(bx) 2 1
330
wait
wait
wait
wait

21. Solution To Lost Update Problem

22. 2PL solution to Uncommitted Dependency Problem
Chapter Name
2PL solution to Uncommitted Dependency Problem
September 98
Time T3 T4
balx t1
begin trans
100 t2
writelock(balx) t3
read(balx) t4
balx = balx +100 t5
write(balx)
200 t6
wait
roll back / unlock(balx) t7 t8
balx = balx - 10 t9 90
t10
commit / unlock(balx)
T4 Growing
T4 Shrinking
T3 Growing
T3 Shrinking 14

23. 2PL solution to Inconsistent Analysis Problem
Chapter Name
September 98
Time T5 T6
balx
baly
balz
sum t1
begin trans
100 50 25 t2
sum = 0 t3
writelock(balx)
readlock(balx) t4
read(balx)
wait t5
balx = balx - 10 t6
write(balx) 90 t7
writelock(balz) t8
read(balz) t9
balz = balz + 10
t10
write(balz) 35
t11
commit/unlock(balx ,balz)
t12
t13
sum = sum + balx
t14
readlock(baly)
t15
read(baly)
t16
sum = sum + baly
140
t17
readlock(balz)
t18
t19
sum = sum + balz
175
t20
commit/unlock(balx baly balz) T5 T5 T6 T6 16

24. Cascading Rollback
Chapter Name
September 98
If every transaction in a schedule follows 2PL, then the schedule is guaranteed to be conflict serializable.
However, problems can occur with interpretation of when locks can be released. 42

25. Cascading Rollback T14 acquires write lock X T14 acquires read lock Y
Chapter Name
September 98
Cascading Rollback
T14 acquires write lock X
T14 acquires read lock Y
writes new X value
T14 releases lock X
T15 acquires write lock X
reads T14’s X value
T15 releases lock X
T14 forced to rollback
T16 acquires read lock X
T15 must also rollback as it has read T14’s X value
T16 must also rollback as it has lock on T15’s X value
Time
T14
T15
T16 t1 t2
begin trans t3
writelock(balx) t4
read(balx) t5
readlock(baly) t6
read(baly) t7
balx = baly + balx t8
write(balx) t9
unlock(balx)
t10 :
t11
balz = balz + 100
t12
t13
t14
t15
rollback
t16
t17
readlock(balx)
t18
t19 43

26. Cascading Rollback
Chapter Name
September 98
Since T15 is dependent on T14, T15 must also be rolled back. Since T16 is dependent on T15, it too must be rolled back. Cascading rollback.
To prevent this with 2PL
leave release of all locks until end of transaction rigorous 2PL. or
hold write locks until the end of the transaction strict 2PL. 44

27. 2PL Protocol versions
Basic 2PL (described above)
Strict 2PL
Rigorous 2PL
Conservative 2PL

28. Strict 2PL
No exclusive locks released until after transaction commits (or aborts)
Guarantees strict schedules
Not deadlock free
The most commonly used two-phase locking algorithm

29. Rigorous 2PL
No exclusive and shared locks released until after transaction commits (or aborts)
Guarantees strict schedules
Not deadlock free
Easier to implement then Strict 2PL

30. Conservative 2PL
All items required by the transaction must be locked before the transaction begins execution
Deadlock free
Difficult to implement on practice

31. Deadlock
Chapter Name
September 98
An impasse that may result when two (or more) transactions are each waiting for locks held by the other to be released.
Time
T17
T18 t1
begin trans t2
writelock(balx)
writelock(baly) t3
balx = balx - 10
read(baly) t4
write(balx)
baly = baly +100 t5
write(baly) t6
wait t7 t8 t9
t10
Deadlocked T18 waiting for a lock held by T17 which is waiting fo a lock held by T18 45

32. Dealing with deadlocks
Approaches:
Deadlock prevention
Deadlock detection
Timeouts

33. Deadlock prevention
A transaction locks all data items it refers to before it begins execution.
This way of locking prevents deadlock since a transaction never waits for a data item.
The conservative two-phase locking uses this approach.
Disadvantages?

34. Deadlock Detection and Recovery
DBMS allows deadlock to occur but recognizes it and breaks it.
Usually handled by construction of wait-for graph (WFG) showing transaction dependencies:
Deadlock exists if and only if WFG contains cycle.
WFG is created at regular intervals.

35. Deadlock Detection and Recovery
Chapter Name
September 98
A WFG is maintained which refuses to allow an action that creates a cycle in the graph.
The WFG has a node for each transaction {Ti, , Tj .. Tn} that currently holds a lock or is waiting for one. 47

36. Deadlock Detection - WFG
An edge from Ti  Tj if there is some data item X such that:
Ti holds a lock on X
Tj is waiting for a lock on X, and
Tj cannot get a lock on X unless Ti first releases

37. Example - Wait-For-Graph (WFG)
Chapter Name
September 98
Edge X
T18 waiting for write lock on balx held by T17 X
T17
T18
Edge Y
T17 waiting for write lock on baly held by T18 Y
Deadlock cycle 50

38. Deadlock detection Draw a WFG for the following schedule.
Does it follow 2PL protocol?
T1 T2
read_lock (Y);
read_item (Y);
read_lock (X);
write_lock (X);
(waits for X)
write_lock (Y);
(waits for Y)

39. Recovery from Deadlock Detection
Several issues:
choice of deadlock victim;
how far to roll a transaction back;
avoiding starvation.

40. Deadlock Prevention Time Stamp
Chapter Name
September 98
A unique identifier created by DBMS that indicates relative starting time of a transaction.
Can be generated by using system clock at the time transaction started, or by incrementing a logical counter every time a new transaction starts.
e.g t5, t6, t7, t8, ... tn 52

41. Deadlock Prevention Time Stamp
The timestamp is used when a transaction Ti is forced to wait for a lock that is held by another transaction Tj.
Two different things happen depending on whether Ti or Tj is older (determined by the earlier timestamp).
t5 before t8 therefore, t5 is older than t8
t0 t5 t8 time (tn)
oldest youngest
t8 after t5 therefore, t8 is younger than t5

42. Deadlock Prevention Wait-Die
Only an older transaction can wait for a younger one, otherwise the transaction is aborted (dies) and is restarted with the same timestamp.
If Ti is older than Tj (i.e the timestamp of Ti < Tj) , then Ti is allowed to wait for the locks held by Tj.
If Tj is older than Ti (i.e the timestamp of Ti > Tj) , then Ti dies; it is rolled back.

43. Deadlock Prevention wait-die
Chapter Name
September 98
In the wait-die protocol there can be no cycle in the WFG, therefore there are no deadlocks.
T1  T2  T3  T1
One of these transactions must be the oldest.
Suppose T2 is older than T1, T1 is older than T3
In wait-die the older transaction waits for a younger transaction,
T2 is allowed to wait for the lock held by T3
it is impossible for T1 to be waiting to lock an item held by T2
it is impossible for T3 to be waiting to lock an item held by T1
One of the younger transactions T1 or T3 would be rolled back and the deadlock broken. 51

44. Deadlock Prevention – Wound-Wait
Chapter Name
September 98
Only a younger transaction can wait for an older one. If an older transaction requests a lock held by a younger one, the younger one is aborted (wounded usually a fatal wound).
If Ti is older than Tj (i.e the timestamp of Ti < Tj) , then Ti wounds Tj. Tj must rollback and relinquish to Ti the locks that Ti needs.
There is an exception, if by the time the wound takes effect, Tj has already finished and released its locks it is allowed to survive and is not rolled back. 48

45. Deadlock Prevention wound-wait
In wound-wait younger transactions wait for the older transaction
T1  T2  T3  T1
One of these transactions must be the oldest.
Suppose T2 is older than T1, T1 is older than T3
In wound-wait the younger transaction waits for an older transaction,
T1 is allowed to wait for the lock on an item held by T2
T3 is allowed to wait for the lock on an item held by T1
it is impossible for T2 to be waiting for a lock held by T3
The older transaction T2 wounds the younger transaction T3 . T2 takes the locks that it needs and the deadlock broken.

46. Deadlock prevention - Timeouts
No waiting protocol
If transaction can not obtain lock it is aborted
Cautious waiting protocol
If transaction T1 is requesting lock on item currently locked by another transaction T2 and if T2 is not blocked then T1 is allowed to wait, otherwise T1 aborted

47. Ranging from coarse to fine:
Lock granularity
Size of data items chosen as unit of protection by concurrency control protocol.
Ranging from coarse to fine:
The entire database.
A file.
A page (or area or database spaced).
A record.
A field value of a record.

48. Best item size depends on the types of transactions.
Lock granularity
Tradeoff:
coarser, the lower the degree of concurrency;
finer, more locking information that is needed to be stored.
Best item size depends on the types of transactions.

49. Levels of Locking

50. Multiple lock granularity
What problems it might cause?
Checking for locks top down
Checking for locks bottom up

51. Multiple lock granularity
To manage such hierarchy, in addition to read and write, three additional locking modes, called intention lock modes are defined:
Intention-shared (IS): indicates that a shared lock(s) will be requested on some descendent nodes(s).
Intention-exclusive (IX): indicates that an exclusive lock(s) will be requested on some descendent nodes(s).
Shared-intention-exclusive (SIX): indicates that the current node is locked in shared mode but an exclusive lock(s) will be requested on some descendent nodes(s).

52. Multiple lock granularity
These locks are applied using the following compatibility matrix:

53. Multiple lock granularity
The lock compatibility must adhered to.
The root of the tree must be locked first, in any mode.
A node N can be locked by a transaction T in S or IX mode only if the parent node is already locked by T in either IS or IX mode.

54. Multiple lock granularity
A node N can be locked by T in X, IX, or SIX mode only if the parent of N is already locked by T in either IX or SIX mode.
T can lock a node only if it has not unlocked any node (to enforce 2PL policy).
T can unlock a node, N, only if none of the children of N are currently locked by T.

55. Examples for MGL protocol

56. Multiple Granularity Locking Example

57. Next lecture…
Other concurrency control techniques
Timestamp ordering
Multiversion timestamp ordering
Optimistic locking
Intro to DB recovery

58. Reading
Conolly Chapter 19
Elmasri Chapter 18