Concurrency Control!

q  How to ensure serializability and recoverability? "

q  Lock-Based Protocols"
q  Lock, 2PL"
q  Lock Conversion "
q  Lock Implementation"
q  Deadlock"
q  Multiple Granularity"
q  Other Protocols"
q  Timestamp-Based, Validation-Based, Multiversion Schemes,
Snapshot isolation"
q  Insert and Delete Operations"

Database Management Systems II, Huiping Cao! 1!

 Lock-Based Protocols!
q  A lock is a mechanism to control concurrent access to a data
item"
q  Data items can be locked in two modes:"
1. exclusive (X) mode. Data item can be both read as well as "
written. X-lock is requested using lock-X instruction."
2. shared (S) mode. Data item can only be read. S-lock is "
requested using lock-S instruction."

Database Management Systems II, Huiping Cao! 2!

 Lock-Based Protocols (Cont.)!
q  Lock-compatibility matrix!

" S X
"
S true false

X false false

Database Management Systems II, Huiping Cao! 3!

 Lock-Based Protocols (Cont.)!
q  Example: "
q  T1 transfers $50 from account B to account A"
q  T2 displays the total amount of money in accounts A and B"
q  Cannot guarantee serializability"

T1: " T2: "

lock-X(B);" lock-S(A);"
read (B);" read (A);"
B=B-50;" unlock(A);"
write(B);" "
unlock(B);" "
lock-X(A);" lock-S(B);"
read (A);" read (B);"
A=A+50;" unlock(B);"
write(A);" display(A+B)!
unlock(X);! !
!
Database Management Systems II, Huiping Cao! 4!
Database Management Systems II, Huiping Cao! 5!
 The Two-Phase Locking Protocol!
q  A locking protocol is a set of rules followed by all transactions
while requesting and releasing locks. "
!
q  2PL!
q  (1) If a transaction T wants to read/modify an object, it first
requests a shared/exclusive lock on the object. "
q  (2) A transaction cannot request additional locks once it
releases any lock."

q  Phase 1: Growing Phase"

q  Phase 2: Shrinking Phase"

Database Management Systems II, Huiping Cao! 6!

 The Two-Phase Locking Protocol!
"
q  Strict two-phase locking"
q  (1) If a transaction T wants to read/modify an object, it first
requests a shared/exclusive lock on the object. "
q  (2) All locks held by a transaction are released when the
transaction is completed. "

Database Management Systems II, Huiping Cao! 7!

 2PL (Cont.)!
q  Differences between 2PL and Strict 2PL"
q  2PL: unlock instructions do not need to appear at the end of the
transaction"
q  Strict 2PL: all unlock must appear at the end"

Lock-X(B)" Lock-X(B)" Lock-S(A)" Lock-S(A)"

Read(B)" Read(B)" Read(A)" Read(A)"
B=B-50" B=B-50" Lock-S(B)" Lock-S(B)"
Write(B)" Write(B)" Read(B)" Unlock(A)"
Lock-X(A)" Lock-X(A)" Display(A+B)" Read(B)"
Read(A)" Unlock(B)" Unlock(A)" Display(A+B)"
A=A+50" Read(A)" Unlock(B)" Unlock(B)"
Write(A)" A=A+50" " "
Unlock(B)" Write(A)" T4 (strict 2PL)" T4ʼ (2PL)"
Unlock(A)" Unlock(A)"
" "
T3 (strict 2PL)" T3 (2PL)"

Database Management Systems II, Huiping Cao! 8!

 2PL and Strict 2PL!
q  Both 2PL and Strict 2PL disallow the following schedule"
q  Guarantee conflict serializability"

T1! T2!
R(A)" "
W(A)" "
" R(A)"
" W(A)"
" R(B)"
" W(B)"
" Commit"
R(B)" "
W(B)"
Commit"

Database Management Systems II, Huiping Cao! 9!

 2PL and Strict 2PL!
q  2PL allows the following schedule"
q  Unrecoverable"
q  Strict 2PL disallows the following schedule"
q  Recoverability"

T1! T2!
R(A)" "
W(A)" "
" R(A)"
" W(A)"
" R(B)"
" W(B)"
" Commit"
Abort" "

Database Management Systems II, Huiping Cao! 10!

 2PL -properties!

q  2PL does NOT ensure freedom from deadlock"

T3! T4!
Lock-X(B)" Lock-S(A)" Lock-X(B)" "
Read(B)" Read(A)" R(B)" "
B=B-50" Lock-S(B)"
Write(B)" Read(B)"
B = B-50" "
Lock-X(A)" Display(A+B)" W(B)" "
Read(A)" Unlock(A)" " Lock-S(A)"
A=A+50" Unlock(B)" " R(A)"
Write(A)" " " Lock-S(B)"
Unlock(B)" T4" Lock-X(A)" "
Unlock(A)"
"
T3"

Database Management Systems II, Huiping Cao! 11!

 T1 "T2" T3 "T4"
----------------------" ----------------------"
W(X)" W(X)"
R(X)" R(X)"
W(X)" R(X)"
Commit" Commit"
Commit" Abort"

S1 region"
S3 region"
-- not conflict serializable"
-- conflict serializable"
-- not view serializable"
-- not recoverable"
-- not recoverable"
"
"

Database Management Systems II, Huiping Cao! 12!

 Implementation of Locking!
q  Lock and unlock requests are handled by the lock manager"
q  Lock table entry:"
q  Number of transactions currently holding a lock"
q  Type of lock held (shared or exclusive)"
q  Pointer to queue of lock requests"
q  Locking and unlocking have to be atomic operations"
q  Lock upgrade: transaction that holds a shared lock can be
upgraded to hold an exclusive lock"

Database Management Systems II, Huiping Cao! 13!

 Implementation of Locking!
17 123

q  The lock manager maintains a data-

structure called a lock table to
T23 T1 T8 T2
record granted locks and pending
requests."

1912
q  The lock table is usually
implemented as an in-memory hash
table indexed on the name of the
T23 data item being locked."
q  Situations"

14
q  a lock request arrives"
q  an unlock message comes"
q  transaction aborts"
T1 T23
q  Keep a list of locks held by each
transaction, to implement this
144 efficiently"
granted
waiting
T8
Database Management Systems II, Huiping Cao! 14!
 Pitfalls of Lock-Based Protocols!
q  Consider the partial schedule"

Lock-X(B)" Lock-S(A)"
Read(B)" Read(A)"
B=B-50" Lock-S(B)" T3! T4!
Write(B)" Read(B)" Lock-X(B)" "
"
 Display(A+B)" R(B)" "
"
Lock-X(A)" Unlock(A)"
B = B-50" "
Read(A)" Unlock(B)"
A=A+50" "
W(B)" "
Write(A)" T4" " Lock-S(A)"
"
 " R(A)"
"
Unlock(B)" " Lock-S(B)"
Unlock(A)" Lock-X(A)" "
T3"

q  Such a situation is called a deadlock. "

Database Management Systems II, Huiping Cao! 15!

 Deadlocks!
q  Deadlock: Cycle of transactions waiting for locks to be released
by each other."
q  Two ways of dealing with deadlocks:"
q  Deadlock prevention"
q  Deadlock detection"

Database Management Systems II, Huiping Cao! 16!

 Deadlock Prevention!
q  Assign priorities based on timestamps. "
q  The lower the timestamp, the higher is the transactionʼs priority. "
q  Assume Ti wants a lock that Tj holds. Two policies are possible:"
q  Wait-Die: It Ti has higher priority (or smaller timestamp), Ti waits
for Tj; otherwise Ti aborts"
q  Wound-wait: If Ti has higher priority (or smaller timestamp), Tj
aborts; otherwise Ti waits"

q  If a transaction re-starts, make sure it has its original timestamp"

q  Older transactions thus have precedence over newer ones"
q  Starvation is hence avoided."
  Starvation:
the same transaction is repeatedly rolled back due
to deadlocks."

Database Management Systems II, Huiping Cao! 17!

 Deadlock prevention (Cont.)!
q  Timeout-Based Schemes"
q  A transaction waits for a lock only for a specified amount of
time. After that, the wait times out and the transaction is
rolled back."
q  Thus deadlocks are not possible"
q  Simple to implement; but starvation is possible. "
q  Difficult to determine good value of the timeout interval."

Database Management Systems II, Huiping Cao! 18!

 Deadlock Detection!
q  Create a waits-for graph:"
q  Nodes are transactions"
q  There is an edge from Ti to Tj if Ti is waiting for Tj to
release a lock"
q  Periodically check for cycles in the waits-for graph"

Database Management Systems II, Huiping Cao! 19!

 Example!
q  Schedule: R1(X) W2(X), W2(Y), W3(Y) W1(Y) Commit-T1, Commit-
T2, Commit-T3"

q  Describe how the concurrency control mechanism handles the

schedule. "
q  Strict 2PL with timestamps used for deadlock prevention. "
q  Strict 2PL with deadlock detection."

Database Management Systems II, Huiping Cao! 20!

 Example!
q  R1(X) W2(X), W2(Y), W3(Y) W1(Y) Commit-T1, Commit-T2, Commit-
T3"
q  Note that we do not interchangeably use both Wait-Die or Wound-Wait"
q  Assume we use deadlock prevention (Wait-Die policy)"
q  R1(X): T1 acquires shared-lock on X; "
q  W2(X): When T2 asks for an exclusive lock on X, since T2 has a
lower priority, it will be aborted; (wait-die)"
q  W3(Y): T3 now gets exclusive-lock on Y; "
q  W1(Y): When T1 also asks for an exclusive-lock on Y which is still
held by T3, T1 will be blocked waiting since T1 has higher priority"
q  T3 now finishes write, commits and releases all the lock; "
q  T1 wakes up, acquires the lock, proceeds and finishes; "
q  T2 now can be restarted successfully."

Database Management Systems II, Huiping Cao! 21!

 Example!
q  R1(X) W2(X), W2(Y), W3(Y) W1(Y) Commit-T1, Commit-T2, Commit-T3"
q  Strict 2PL with deadlock detection."
q  T1 gets a shared-lock on X; "
q  T2 blocks waiting for an exclusive-lock on X; (No prevention)"
  Think what will happen if we apply deadlock prevention (wait-die/wound-wait)"
q  T3 gets an exclusive-lock on Y;"
q  T1 blocks waiting for an exclusive-lock on Y; (No prevention)"
  Think what will happen if we apply deadlock prevention (wait-die/wound-wait)"
q  T3 finishes, commits and releases locks;"
q  T1 wakes up, gets an exclusive-lock on Y, finishes up and releases lock on X
and Y; "
q  T2 now gets both an exclusive-lock on X and Y, and proceeds to finish. "
q  No deadlock."
q  R1(X), W2(Y), W2(X), W3(Y), W1(Y), Commit-T1, Commit-T2, Commit-T3"

Database Management Systems II, Huiping Cao! 22!

 Deadlock Detection (Continued)!

Example:"
"
T1: S(A), R(A), " S(B)"
T2: " " X(B),W(B) " " X(C)"
T3: " " " " S(C), R(C)" " X(A)"
T4: " " " " " " X(B)"
"
"
T1" T2" T1" T2"

T4" T3" T4" T3"

Database Management Systems II, Huiping Cao! 23!

 Deadlock Recovery!
q  When deadlock is detected, some transaction will have to
rolled back (made a victim) to break deadlock. "
q  Select a transaction as victim that will incur minimum
cost."
q  Rollback -- determine how far to roll back transaction"
  Total rollback: Abort the transaction and then restart it."
  Moreeffective to roll back transaction only as far as
necessary to break deadlock."
q  Starvation happens if same transaction is always chosen
as victim. Include the number of rollbacks in the cost factor
to avoid starvation"

Database Management Systems II, Huiping Cao! 24!

 Multiple-Granularity Locks!
q  Hard to decide what granularity to lock (tuples vs. pages vs. tables)."
q  Should not have to decide!"
q  Data containers are nested: "
q  Granularity of locking (level in tree where locking is done):"
q  fine granularity (lower in tree): high concurrency, high locking
overhead"
q  coarse granularity (higher in tree): low locking overhead, low
concurrency"
Database"
Database"

Tables"
Tables"
contains"
Pages"
Pages"

Tuples"
Tuples"

Database Management Systems II, Huiping Cao! 25!

 Solution: New Lock Modes, Protocol!
q  Question: Ti ask a lock on page, while Tj holds a lock on the file
that this page belongs to"
q  Allow transactions to lock at each level, but with a special
protocol using new intention locks:"

Database Management Systems II, Huiping Cao! 26!

 Intention Lock Modes!
q  Three additional lock modes with multiple granularity:"
q  intention-shared (IS): indicates explicit locking at a lower level of
the tree but only with shared locks."
q  intention-exclusive (IX): indicates explicit X locking at a lower
level or shared locks"
q  shared and intention-exclusive (SIX): the subtree rooted by that
node is locked explicitly in shared mode and explicit locking is
being done at a lower level with X locks."
q  Before locking an item, transaction must set intention locks on all its
ancestors."
q  For unlock, go from specific to general (i.e., bottom-up)."

Database Management Systems II, Huiping Cao! 27!

 Compatibility Matrix with Intention Lock Modes!

q  The compatibility matrix for all lock modes is: "

IS IX S SIX X
IS true true true true false
IX true true false false false
S true false true false false
SIX true false false false false
X false false false false false

Database Management Systems II, Huiping Cao! 28!

 Examples!

q  T1 scans R, and updates a few tuples:"

q  T1 gets an SIX lock on R, then repeatedly gets an S lock on
tuples of R, and occasionally upgrades to X on the tuples."
q  T2 uses an index to read only part of R:"
q  T2 gets an IS lock on R, and repeatedly gets an S lock on
tuples of R."
q  T3 reads all of R:"
q  T3 gets an S lock on R. "
q  OR, T3 could behave like T2; can use lock escalation to
decide which."

Database Management Systems II, Huiping Cao! 29!

 q  Concurrency control without locking "
q  Self-study all the later materials"

Database Management Systems II, Huiping Cao! 30!

 Timestamp-Based Protocols!
q  Each transaction is issued a timestamp when it enters the system. If
an old transaction Ti has time-stamp TS(Ti), a new transaction Tj is
assigned time-stamp TS(Tj) such that TS(Ti) <TS(Tj). "
q  System clock, logical counter"
q  The protocol maintains for each data Q two timestamp values:"
q  W-timestamp(Q) is the largest time-stamp of any transaction
that executed write(Q) successfully."
q  R-timestamp(Q) is the largest time-stamp of any transaction
that executed read(Q) successfully."

Database Management Systems II, Huiping Cao! 31!

 Timestamp-Based Protocols (Cont.)!
q  The timestamp ordering protocol ensures that any conflicting read and
write operations are executed in timestamp order."
q  Suppose a transaction Ti issues a read(Q):"
1.  If TS(Ti) ≤ W-timestamp(Q), then Ti needs to read a value of Q
that was already overwritten."
  Hence, the read operation is rejected, and Ti is rolled back."
  When Ti restarts, a new and larger timestamp is assigned to
Ti"
2.  If TS(Ti)≥ W-timestamp(Q), then the read operation is executed,
and R-timestamp(Q) is set to max(R-timestamp(Q), TS(Ti))."

Database Management Systems II, Huiping Cao! 32!

 Timestamp-Based Protocols (Cont.) (S.S)!
q  Suppose that transaction Ti issues write(Q)."
1.  If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is
producing was needed previously, and the system assumed that
that value would never be produced. "
  Hence, the write operation is rejected, and Ti is rolled back."
2.  If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an
obsolete value of Q. "
  Hence, this write operation is rejected, and Ti is rolled back."
"
3.  Otherwise, the write operation is executed, and W-timestamp(Q)
is set to TS(Ti)."

Database Management Systems II, Huiping Cao! 33!

 Example Use of the Protocol!
A partial schedule for several data items for transactions with"
timestamps 1, 2, 3, 4, 5"

Database Management Systems II, Huiping Cao! 34!

 Correctness of Timestamp-Ordering Protocol!

q  The timestamp-ordering protocol guarantees serializability since all

the arcs in the precedence graph are of the form:"
"
"
"
"
"
Thus, there will be no cycles in the precedence graph."
q  Timestamp protocol ensures freedom from deadlock as no
transaction ever waits. "
q  But the schedule may not be cascade-free, and may not even be
recoverable."
T1 "T2"
----------------------"
W(A)"
R(A)"
W(B)"
Commit"

Database Management Systems II, Huiping Cao! 35!

 Correctness of Timestamp-Ordering Protocol (S.S)!
q  But the schedule may not be cascade-free, and may not even be
recoverable."

T1 "T2"
----------------------"
W(A)"
R(A)"
W(B)"
Commit"

An Unrecoverable Schedule"

Database Management Systems II, Huiping Cao! 36!

 Recoverability and Cascade Freedom (S.S)!
q  Solution 1:"
q  A transaction is structured such that its writes are all performed
at the end of its processing"
q  All writes of a transaction form an atomic action; no transaction
may execute while a transaction is being written"
A transaction that aborts is restarted with a new timestamp"
q 
q  Solution 2: Limited form of locking: wait for data to be committed
before reading it"
q  Solution 3: Use commit dependencies to ensure recoverability"

Database Management Systems II, Huiping Cao! 37!

 Thomas Write Rule (S.S.)!
q  Modified version of the timestamp-ordering protocol in which obsolete
write operations may be ignored under certain circumstances."
q  When Ti attempts to write data item Q, if TS(Ti) < W-timestamp(Q),
then Ti is attempting to write an obsolete value of {Q}. "
q  Rather than rolling back Ti as the timestamp ordering protocol
would have done, this {write} operation can be ignored."
q  Otherwise this protocol is the same as the timestamp ordering
protocol."
q  Thomas' Write Rule allows greater potential concurrency. "

q  Allows some view-serializable schedules that are not conflict-

serializable."

Database Management Systems II, Huiping Cao! 38!