Embed Size (px)
Citation preview
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
18.4.1 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 principles1. 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
18.4.1 Shared & Exclusive Locks (cont.) Two-phase locking (2PL) of transactions
Ti
Notation: sli (X)– Ti requests shared lock on DB element X
xli (X)– Ti requests exclusive lock on DB element X
ui (X)– Ti relinquishes whatever lock on X
4
Lock R/W Unlock
18.4.1 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
18.4.2 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
S X
Lock inhold
S YES NO
X NO NO
18.4.3 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
18.4.3 Upgrading Locks (cont.) Observe the example
T1 cannot take an exclusive lock on B until all locks on B are
released.
‘B’ is releasedT1 retry and
succeed
18.4.3 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 !!
18.4.4 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: uli (X) 10
18.4.4 Update locks (cont.)
Example
18.4.4 Update locks (cont.)
• Compatibility matrix (asymmetric)
12
Lock requestedS X U
Lock inhold
S YES NO YES
X NO NO NO
U NO NO NO
18.4.5 Increment Locks
A useful lock for transactions which increase/decrease value. e.g. money transfer between two bank accounts.
If 2 transactions (T1, T2) 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
18.4.5 Increment Locks (cont.)
A=5
A=15
A=17
A=7T1: INC (A,2)
T1: INC (A,2)
T2: INC (A,10)
T2: INC (A,10)
CASE 1
CASE 2
18.4.5 Increment Locks (cont.)
What if
A=5
A=15
A=15
A=7T1: INC (A,2)
T1: INC (A,2)
T2: INC (A,10)
T2: INC (A,10)
A=5 A=7
A != 17
A=5
A=5
18.4.5 Increment Locks (cont.)
INC (A, c) – Increment action of writing on database element
A, which is an atomic execution consisting of1. READ(A,t);2. t = t+c;3. WRITE(A,t);
Notation: ili (X)– action of Ti requesting an increment lock on X inci (X)– action of Ti increments X by some constant;
don’t care about the value of the constant.
18.4.5 Increment Locks (cont.)
Example
18.4.5 Increment Locks (cont.)
18
• Compatibility matrix
Lock requestedS X I
Lock inhold
S YES NO NO
X NO NO NO
I NO NO YES
References
H. Garcia-Molina, J. Ullman, and J. Widom, “Database System: The Complete Book,” second edition: chapter 18.3-18.4, p.897-913, Prentice Hall, New Jersy, 2008
20
21
For your attention
