1 Concurrency Control: 18.4 Locking Systems with Several Lock Modes CS257 Spring/2009 Professor: Tsau Lin Student: Suntorn Sae-Eung ID: 212

18.4 Locking Systems with Several Lock Modes In 18.3, if a transaction must lock a database element (X) either reads or writes, No reason why several transactions could not read X at the same time, as long as none write X Introduce locking schemes Shared/Read Lock ( For Reading) Exclusive/Write Lock( For Writing) 2

Shared & Exclusive Locks Transaction Consistency Cannot write without Exclusive Lock Cannot read without holding some lock Consider lock for writing is “stronger” than for reading This basically works on 2 principles 1. A read action can only proceed a shared or an exclusive lock 2. A write lock can only proceed a exclusive lock All locks need to be unlocked before commit 3

Shared & Exclusive Locks (cont.) Two-phase locking (2PL) of transactions T i Notation: sl i (X)– T i requests shared lock on DB element X xl i (X)– T i requests exclusive lock on DB element X u i (X)– T i relinquishes whatever lock on X 4 Lock  R/W  Unlock

Shared & Exclusive Locks (cont.) Legality of Schedules An element may be locked by: one write transaction or by several read transactions shared mode, but not both

Compatibility Matrices A convenient way to describe lock- management policies Rows correspond to a lock held on an element by another transaction Columns correspond to mode of lock requested. Example : 6 Lock requested SX Lock in hold SYESNO X

Upgrading Locks A transaction (T) taking a shared lock is friendly toward other transaction. When T wants to read and write a new value X, 1. T takes a shared lock on X. 2. performs operations on X (may spend long time) 3. When T is ready to write a new value, “Upgrade” shared lock to exclusive lock on X. 7

Upgrading Locks (cont.) Observe the example T 1 cannot take an exclusive lock on B until all locks on B are released. ‘B’ is released T1 retry and succeed

Upgrading Locks (cont.) Upgrading can simply cause a “Deadlock”. Both the transactions want to upgrade on the same element 9 Both transactions will wait forever !!

Update locks The third lock mode resolving the deadlock problem, which rules are Only “Update lock” can be upgraded to a write (exclusive) lock later. An “Update lock” is allowed to grant on X when there are already shared locks on X. Once there is an “Update lock,” it prevents additional any kinds of lock, and later changes to a write (exclusive) lock. Notation: ul i (X) 10

Update locks (cont.) Example

Update locks (cont.) Compatibility matrix (asymmetric) 12 Lock requested SXU Lock in hold SYESNOYES XNO U

Increment Locks A useful lock for transactions which increase/decrease value. e.g. money transfer between two bank accounts. If 2 transactions (T 1, T 2 ) add constants to the same database element (X), It doesn’t matter which goes first, but no reads are allowed in between transaction processing Let see on following exhibits 13

Increment Locks (cont.) A=5 A=15 A=17 A=7 T 1 : INC (A,2) T 2 : INC (A,10) CASE 1 CASE 2

Increment Locks (cont.) What if A=5 A=15 A=7 T 1 : INC (A,2) T 2 : INC (A,10) A=5A=7 A != 17 A=5

Increment Locks (cont.) INC (A, c) – Increment action of writing on database element A, which is an atomic execution consisting of 1. READ(A,t); 2. t = t+c; 3. WRITE(A,t); Notation: il i (X)– action of T i requesting an increment lock on X inc i (X)– action of T i increments X by some constant; don’t care about the value of the constant.

Increment Locks (cont.) Example

Increment Locks (cont.) 18 Compatibility matrix Lock requested SXI Lock in hold SYESNO X I YES

References H. Garcia-Molina, J. Ullman, and J. Widom, “Database System: The Complete Book,” second edition: chapter , p , Prentice Hall, New Jersy,

21 For your attention