Lecture 3 Concurrency control techniques Database Management Lecture 3 Concurrency control techniques

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

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.

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

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

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.

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.

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.

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

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.

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.

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.

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

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)

Locking Does use of locks guarantee serializability on its own?

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

Incorrect locking schedule If at start, balx = 100, baly = 400, the serial result should be: if T9 executes before T10 then balx = (100 +100) * 1.1 = 220 baly = (400 -100) * 1.1 = 330 or if T10 executes before T9 then balx = (100 * 1.1) + 100 = 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.

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

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.

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

Solution To Lost Update Problem

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

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

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

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

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

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

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

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

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

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

Dealing with deadlocks Approaches: Deadlock prevention Deadlock detection Timeouts

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?

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.

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

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

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

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)

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

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

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

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.

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

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

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.

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

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.

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.

Levels of Locking

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

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).

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

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.

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.

Examples for MGL protocol

Multiple Granularity Locking Example

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

Reading Conolly Chapter 19 Elmasri Chapter 18