Univ.

of Crete

D. Plexousakis CS460 Fall 2005

Concurrency Control

2-Phase Locking: all lock requests precede all unlock requests Idea: Ti = . li(A) ... ui(A) ...

# locks held by Ti

no unlock

no locks

time Growing
Lecture 3

Shrinking Phase
1

Phase

Univ. of Crete

D. Plexousakis CS460 Fall 2005

2-Phase Locking

Intuitively, each 2PL transaction may be thought to execute in its entirety at the moment it releases the first item The conflict-equivalent serial schedule for a schedule S of 2PL transactions is the one in which transactions are ordered in the same order as their first unlocks Conversion: by induction on the number n of transactions in a legal schedule S Note: conversion requires swapping the order of read and write operations; while that is is done, locks and unlocks can be ignored; once the actions are arranged serially, lock / unlock operations can be added

Lecture 3

Univ. of Crete

D. Plexousakis CS460 Fall 2005

2-Phase Locking
Conversion

by Induction Base case: n=1; S is already a serial schedule Induction: Let S involve transactions T1, T2, , Tn; let Ti be the first transaction to unlock an item by op. Ui(X). Then, it is possible to move all read/write actions of Ti to the beginning of S without passing any conflicting action. Let Ti include an action Wi(Y). If there existed an action Wj(Y) in S that precedes Wi(Y), then Uj(Y) and Li(Y) must also appear between Wj(Y) and Wi(Y). We assumed that Ui(X) is the first unlock, hence it precedes Uj(Y). This means that Ui(X) must also appear before Li(Y). But then, Ti is not a 2PL transaction.
3

Lecture 3

Univ. of Crete

D. Plexousakis CS460 Fall 2005

2PL and Deadlocks

2PL cannot prevent deadlocks Example: consider the following schedule : L1(A), R1(A), L2(B), R2(B), W1(A), W2(B), L1(B), L2(A) denied Each transaction waits for the other to release a lock

Lecture 3

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Beyond Simple 2PL

Improvements to 2PLs performance for allowing more concurrency: shared locks multiple granularities inserts, deletes and phantoms other types of concurrency control mechanisms Shared Locks so far locks have been of a single type: exclusive read operations do not conflict no need to lock exclusively for read SLi(X): Ti requests a shared lock on X XLi(X): Ti requests an exclusive lock on X Ui(X): Ti releases lock on X

Lecture 3 5

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Requirements

Consistency An action Ri(X) must be preceded by SLi(X) or XLi(X) with no intervening Ui(X) An action Wi(X) must be preceded by XLi(X) with no intervening Ui(X) All locks must be followed by an unlock of the same element 2PL For any 2PL transaction Ti, no SLi(X) or XLi(X) can be preceded by Ui(X) Legality If XLi(X) appears in a schedule, then there cannot be a following XLj(X) or SLj(X) for j<>i without an intervening Ui(X) If SLi(X) appears in a schedule, then there cannot be a following XLj(X) for j<>i without an intervening Ui(X)
Lecture 3 6

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Example
Consider

the following 2PL transactions T1: SL1(A), R1(A), XL1(B), R1(B), W1(B), U1(A), U1(B) T2: SL2(A), R2(A), SL2(B), R2(B), U2(A), U2(B) A legal interleaved execution of T1, T2 is as follows:
T1 SL1(A), R1(A) SL2(A), R2(A), SL2(B), R2(B) XL1(B) wait U2(A), U2(B) XL1(B), R1(B), W1(B) U1(A), U1(B)
Lecture 3 7

T2

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Upgrading Locks

A transaction that wants to read and write an item, may first obtain a shared lock on the item for reading and then upgrade it to an exclusive lock for writing
Example: T1: SL1(A), R1(A), SL1(B), R1(B), XL1(B), W1(B), U1(A), U1(B) T2: SL2(A), R2(A), SL2(B), R2(B), U2(A), U2(B) T1 SL1(A), R1(A) SL1(B), R1(B), XL1(B) wait SL2(A), R2(A), SL2(B), R2(B) T2

Lecture 3

XL1(B), W1(B), U1(A), U1(B)

U2(A), U2(B)
8

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Upgrading Locks

Lock upgrading may lead to deadlocks Example:

T1 SL1(A), R1(A)

T2

SL2(A), R2(A) XL1(A) wait XL2(A) wait

Lecture 3

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Update Locks

We can avoid deadlocks caused by lock upgrade by using update locks: An update lock ULi(X) allows transaction Ti to read X but not to write X Only an update lock can be upgraded to a write lock An update lock can be granted on X when there are already shared locks on X Once there is an update lock on X , no additional locks are allowed on X (otherwise such a lock would never be upgraded to exclusive)

Lecture 3

10

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Example
T1: UL1(A), R1(A), XL1(A), W1(A), U1(A) T2: UL2(A), R2(A), XL2(A), W2(A), U2(A) T1 UL1(A), R1(A) UL2(A) wait XL1(A), W1(A), U1(A) UL2(A), R2(A), XL2(A), W2(A), U2(A) T2

Lecture 3

11

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Increment Locks

Several transactions operate on DB items by simply adding or subtracting constants E.g., money transfer between accounts, seat reservations Such transactions commute with each other and their relative order doesnt matter However, they dont commute with transactions that read or write Assume transactions may include operations of the form INC(A,c), meaning that constant c is to be added to DB element A INC(A,c) stands for: Read(A,t); t:=t+c; Write(A,t); Increment actions need increment locks: ILi(X)
12

Lecture 3

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Increment Locks

Increment locks do not enable reads or writes Requirements: A consistent transaction can perform INCi(X) only if it is preceded by ILi(X) In a legal schedule, any number of transactions can hold an increment lock on item X at a time. If a transaction has an increment lock on X, no other transaction can have a shared or exclusive lock on X at the same time. INCi(X) conflicts with Rj(X) and Wj(X) for j<>I INCi(X) does not conflict with INCj(X)

Lecture 3

13

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Example
T1: SL1(A), R1(A), IL1(B), INC1(B), U1(A), U1(B) T2: SL2(A), R2(A), IL2(B), INC2(B), U2(A), U2(B) T1 SL1(A), R1(A) SL2(A), R2(A),IL2(B), INC2(B) IL1(B), INC1(B) U2(A), U2(B) U1(A), U1(B) T2

Lecture 3

14

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Granularity Issues
Locking works well, but should we lock small or large objects? If large objects (e.g., relations) are locked Need few locks Low concurrency If small objects (e.g., tuples, attributes) are locked Need more locks More concurrency We can do both. Stall 1 Stall 2 Stall 3 Stall 4 The bathroom metaphor:

restroom

Lecture 3

hall Locking on Hierarchies of DB Elements

15

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Assume there is a tree structure to the data Hierarchy of lockable elements (relations, tuples, attributes) Data organized in a tree (e.g., a B+-tree) Locking schemes seen so far perform poorly in such cases 3 levels of DB elements: Relations are the largest lockable elements Each relation comprises one or more blocks Each block contains one or more tuples Need a new type of lock, called a warning lock

Lecture 3

16

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Warning Locks

Ordinary locks: S (shared), X (exclusive) Warning locks denote the intention to obtain a lock IS: intention to obtain a shared lock IX: intention to obtain an exclusive lock Rules: To place a S or X lock, start at the root of the hierarchy If at the element that we want to lock, request S or X lock If the element is further down the hierarchy, place a warning of the appropriate kind at the current node Proceed to the appropriate child node and repeat until the desired node is reached
17

Lecture 3

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Warning Locks

Compatibilities: An IS on a node N is only incompatible with an X lock on N An IX on a node N is incompatible with S and X on N Potential conflicts that may arise with IS/IS, IS/IX, IX/IS and IX/IX will be resolved at a lower level An S on N is compatible with IS and S An X on N is incompatible with every other type of lock Can only lock existing items, but not items that might later be inserted. To handle insertions / deletions:

Get exclusive lock on A before deleting A At insert A operation by Ti,Ti is given exclusive lock on A
18

Lecture 3

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Phantoms

Phantoms are tuples that should have been locked but they werent because they didnt exist at the time the locks were granted Example:

relation R (E#,name,) constraint: E# is key use tuple locking

R
o1 o2
Lecture 3

E#
55 75

Name
Smith Jones

19

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Example
T1: Insert <99,Gore,> into R T2: Insert <99,Bush,> into R T1 S1(o1) S1(o2) Check Constraint

T2
S2(o1) S2(o2) Check Constraint

...

Insert o3[99,Gore,..] Insert o4[99,Bush,..]

Lecture 3 20

...

Univ. of Crete

D. Plexousakis CS460 Fall 2005

Example
Solution relies on using multiple granularities: before insertion at node N, lock parent of N in exclusive mode T1 X1(R) Check Constraint Insert o3[99,Gore,..] U(R) X2(R) Check Constraint tuple with e# 99 already exists
Lecture 3 21

T2
X2(R) wait