Concurrency Control II

Concurrency Control II
General Overview
s Relational model - SQL
Formal & commercial query languages

s Functional Dependencies s Normalization s Physical Design s Indexing s Query Processing and Optimization s Transaction Processing and CC
Database System Concepts
15.2
Review: AC[I]D
s Isolation
Concurrent xctions unaware of each other

s How?
Serial execution of transactions

Poor Throughput and response time
Ensure concurrency
Prevent bad concurrency and allow only good concurrency
through analysis of schedules s Allow only conflict serializable schedules: schedules that are
equivalent to (some) serial schedules.

s Precedence graph: If PS is acyclic confl. serializable schedule
15.3
How to enforce serializable schedules?

prevent P(S) cycles from occurring using a concurrency control manager: ensures interleaving of operations amongst concurrent xctions only result in serializable schedules. T1 T2 .. Tn
CC Scheduler DB
Database System Concepts 15.4
s Reading Uncommitted Data (WR Conflicts, dirty reads):
Anomalies with Interleaved Execution
s Unrepeatable Reads (RW Conflicts):
T1: T2:
R(A), W(A), R(A), W(A), C
R(B), W(B), Abort
T1: T2:
R(A), R(A), W(A), C
R(A), W(A), C
15.5
Anomalies (Continued)
s Overwriting Uncommitted Data (WW Conflicts):
T1: T2:
W(A), W(A), W(B), C
W(B), C
Solution: Use appropriate CC Protocols to achieve serializable schedules
15.6
Agenda
s 2PL and variants s Timestamp-based s Optimistic CC: Validation-based protocols s Multiple granularity s Multi-version s Weaker Consistency (other than serializability) s Dealing with Deadlocks
15.7
The Two-Phase Locking Protocol

s This is a protocol which ensures conflict-serializable schedules. s Phase 1: Growing Phase
transaction may obtain locks transaction may not release locks

s Phase 2: Shrinking Phase
transaction may release locks transaction may not obtain locks

s The protocol assures serializability. It can be proved that the
transactions can be serialized in the order of their lock points (i.e. the point where a transaction acquired its final lock). Locks can be either X, or S/X.
15.8
Lock-Based Concurrency Control

s Strict Two-phase Locking (Strict 2PL) Protocol:
Each Xact must obtain a S (shared) lock on object before reading, and an X (exclusive) lock on object before writing. All locks held by a transaction are released when the transaction completes If an Xact holds an X lock on an object, no other Xact can get a lock (S or X) on that object.
s Strict 2PL allows only serializable schedules.
Has no cascading rollbacks (as locks are released only when txn completes)
15.9
Agenda
15.10
Timestamp-Based Protocols
s Idea:
Decide in advance ordering of xctions Ensure concurrent schedule serializes to serial order decided
Timestamps
1. TS(Ti) is time Ti entered the system 2. Data item timestamps:

1. W-TS(Q): Largest timestamp of any xction that wrote Q 2. R-TS(Q): Largest timestamp of any xction that read Q
Timestamps -> serializability order
15.11
Timestamp CC
s Idea: If action pi of Xact Ti conflicts with action qj of Xact Tj, and TS(Ti) < TS(Tj), then pi must occur before qj. Otherwise, restart violating Xact.
15.12
When Xact T wants to read Object O

s If TS(T) < W-TS(O), this violates timestamp order of T w.r.t. writer
of O.
So, abort T and restart it with a new, larger TS. (If restarted with same TS, T will fail again!)
s If TS(T) > W-TS(O):
Allow T to read O. Reset R-TS(O) to max(R-TS(O), TS(T))

s Change to R-TS(O) on reads must be written to disk! This and
restarts represent overheads.

U writes O T reads O
T start
U start
15.13
When Xact T wants to Write Object O

s If TS(T) < R-TS(Q), then the value of Q that T is producing was
needed previously, and the system assumed that that value would never be produced. write rejected, T is rolled back.
s If TS(T) < W-TS(Q), then T is attempting to write an obsolete value
of Q. Hence, this write operation is rejected, and T is rolled back.

s Otherwise, the write operation is executed, and W-TS(Q) is set to
TS(T).
U reads Q T writes Q
T start
U start
15.14
When Xact T wants to Write Object O

s If TS(T) < R-TS(Q), this violates timestamp order of T w.r.t. writer of
Q; abort and restart T.

s If TS(T) < WTS(Q), violates timestamp order of T w.r.t. writer of Q. Thomas Write Rule: We can safely ignore such outdated writes; need not restart T! (Ts write is effectively followed by another write, with no intervening reads.) Allows some serializable but non conflict serializable schedules: s Else, allow T to write O.
Allows non-Conflict-serializable schedules
T1 T2 R(A) W(A) Commit W(A)
15.15
How Locking works in practice
Ti Read(A),Write(B)
lock table
Scheduler, part I
l(A),Read(A),l(B),Write(B)
Scheduler, part II
Read(A),Write(B) DB
15.16
Agenda
15.17
Optimistic CC (Kung-Robinson)
s Locking is a conservative approach in which conflicts are
prevented. Disadvantages:
Lock management overhead. Deadlock detection/resolution. Lock contention for heavily used objects.
s If conflicts are rare, we might be able to gain concurrency by not
locking, and instead checking for conflicts before Xacts commit.
15.18
Optimistic CC: Kung-Robinson Model

s Xacts have three phases:
READ: Xacts read from the database, but make changes to private copies of objects. VALIDATE: Check for conflicts. WRITE: Make local copies of changes public.
old modified objects

ROOT new
Validation
s Test conditions that are sufficient to ensure that no conflict
occurred.
s Each Xact is assigned a numeric id.
Just use a timestamp.

s Xact ids assigned at end of READ phase, just before validation
begins. (Why then?)

s ReadSet(Ti): Set of objects read by Xact Ti. s WriteSet(Ti): Set of objects modified by Ti.
15.20
Test 1
s For all i and j such that Ti < Tj, check that Ti completes before Tj
begins.
Ti
R V W R
Tj
V W
15.21
Test 1
s For all i and j such that Ti < Tj, check that Ti completes before Tj
begins.
Ti
R V W R
Tj
V W
15.22
Test 2
s For all i and j such that Ti < Tj, check that:
Ti completes before Tj begins its Write phase + WriteSet(Ti)

ReadSet(Tj) is empty.
Ti
V R
W V W
Tj
Does Tj read dirty data? Does Ti overwrite Tjs writes?

Test 3
s For all i and j such that Ti < Tj, check that:
Ti completes Read phase before Tj does + WriteSet(Ti) WriteSet(Ti)

ReadSet(Tj) is empty + WriteSet(Tj) is empty.
Ti
R R
V V
W W
Tj
Does Tj read dirty data? Does Ti overwrite Tjs writes?

Example of what validation must prevent:
RS(T2)={B} WS(T2)={B,D}
RS(T3)={A,B} WS(T3)={C}
=
T3
validated
T2
start
T3
start
T2
validated
time
15.25
Example of what validation must allow: RS(T2)={B} WS(T2)={B,D}
RS(T3)={A,B} WS(T3)={C}
T2
start
T3
start
T2
validated
T3
validated
T2 finish phase 3
T3
start
time
15.26
Another thing validation must prevent: RS(T2)={A} RS(T3)={A,B} WS(T2)={D,E} WS(T3)={C,D}
T2
validated
T3
validated finish
BAD: w3(D) w2(D)
T2
time
15.27
Another thing validation must allow: RS(T2)={A} RS(T3)={A,B} WS(T2)={D,E} WS(T3)={C,D}
T2
validated finish
T3
validated
T2
finish
T2
time
15.28
Comments on Serial Validation

s Assignment of Xact id, validation, and the Write phase are inside
a critical section!
I.e., Nothing else goes on concurrently. If Write phase is long, major drawback.
s Optimization for Read-only Xacts:
Dont need critical section (because there is no Write phase).
15.29
Overheads in Optimistic CC
s Must record read/write activity in ReadSet and WriteSet per Xact.
Must create and destroy these sets as needed.

s Must check for conflicts during validation, and must make validated
writes ``global.
Critical section can reduce concurrency. Scheme for making writes global can reduce clustering of objects.
s Optimistic CC restarts Xacts that fail validation.
Work done so far is wasted; requires clean-up.
15.30
``Optimistic 2PL
s If desired, we can do the following:
Set S locks as usual. Make changes to private copies of objects. Obtain all X locks at end of Xact, make writes global, then release all locks.
s In contrast to Optimistic CC as in Kung-Robinson, this scheme
results in Xacts being blocked, waiting for locks.

However, no validation phase, no restarts (modulo deadlocks).
15.31
Agenda
15.32
Multiple Granularity
s Allow data items to be of various sizes and define a hierarchy of
data granularities, where the small granularities are nested within larger ones
s When a transaction locks a node in the hierarchy explicitly, it
implicitly locks all the node's descendents in the same mode.
Database contains Tables Pages Tuples
15.33
Multiple Granularity
s If we lock large objects (e.g., Relations)
Need few locks Low concurrency

s If we lock small objects (e.g., tuples,fields)
Need more locks More concurrency
15.34
Example of Granularity Hierarchy
The highest level in the example hierarchy is the entire database. The levels below are of type area, file or relation and record in that order.
Multiple-Granularity Locks
s Hard to decide what granularity to lock (tuples vs. pages vs.
tables).
s Shouldnt have to decide! s Data containers are nested:
Database contains Tables Pages Tuples

Solution: New Lock Modes, Protocol
s Allow Xacts to lock at each level, but with a special protocol
using new intention locks:
Before locking an item, Xact must set intention locks on all its ancestors. For unlock, go from specific to general (i.e., bottom-up). SIX mode: Like S & IX at the same time.
15.37
--
IS IX S
IS IX S X
Multiple Granularity Lock Protocol
s Each Xact starts from the root of the hierarchy. s To get S or IS lock on a node, must hold IS or IX on parent node.
What if Xact holds SIX on parent? S on parent?

s To get X or IX or SIX on a node, must hold IX or SIX on parent
node.
s Must release locks in bottom-up order.
Protocol is correct in that it is equivalent to directly setting locks at the leaf levels of the hierarchy.
Compatibility Matrix with Intention Lock Modes

s The compatibility matrix for all lock modes is: requestor
IS IS IX
holder
IX
S IX
S S IX X
15.39
Parent locked in
Child can be locked in
P C
IS IX S SIX X
IS, S IS, S, IX, X, SIX [S, IS] not necessary X, IX, [SIX] none
15.40
Example T1(IS) , T2(IX)
R1 t1 t2
T1(S)
t3
t4
T2(X)
15.41
Multiple Granularity Locking Scheme

s Transaction Ti can lock a node Q, using the following rules:
(1) Follow multiple granularity comp function

Lock root of tree first, any mode Node Q can be locked by Ti in S or IS only if
parent(Q) can be locked by Ti in IX or IS

Node Q can be locked by Ti in X,SIX,IX only
if parent(Q) locked by Ti in IX,SIX (2) Ti is two-phase (2PL) (3) Ti can unlock node Q only if none of Qs children are locked by Ti Observe that locks are acquired in root-to-leaf order, whereas they are released in leaf-to-root order.
T1(IX)
Examples
R
T1(IS)
R t3 t4
T1(S)
T1(IX)
t1
T1(X)
f2.1
t2
t1
t2
t3
t4
f2.2
f4.2
f4.2 f2.1 f2.2 f4.2 f4.2
Can T2 access object f2.2 in X mode? What locks will T2 get?

s Parent s IS s IX s S s SIX s X
T1(SIX)
Child IS,S IS,S, IX, X, SIX [S, IS] not necessary X, IX, [SIX] none
15.43
R
T1(IX)
t1
t2
t3
T1(X)
f4.2
t4
f2.1
f2.2
f4.2
Agenda
15.44
Multiversion Schemes
s Multiversion schemes keep old versions of data item to increase
concurrency.
Multiversion Timestamp Ordering Multiversion Two-Phase Locking
s Each successful write results in the creation of a new version of
the data item written.

s Use timestamps to label versions. s When a read(Q) operation is issued, select an appropriate
version of Q based on the timestamp of the transaction, and return the value of the selected version.
s reads never have to wait as an appropriate version is returned
immediately.
15.45
More on Consistency
s We have seen thus far: Serializability -- 2PL and timestamp s Weaker levels of consistency 1. Degree-two consistency: differs from two-phase locking in that
S-locks may be released at any time, and locks may be acquired at any time
X-locks must be held till end of transaction Serializability is not guaranteed, programmer must ensure that no erroneous database state will occur
1. Cursor stability:
For reads, each tuple is locked, read, and lock is immediately released X-locks are held till end of transaction Special case of degree-two consistency
15.46
Weak Levels of Consistency in SQL

s SQL allows non-serializable executions Serializable: is the default
Repeatable read: allows only committed records to be read, and repeating a read should return the same value (so read locks should be retained) However, the phantom phenomenon need not be prevented T1 may see some records inserted by T2, but may not see others inserted by T2 Read committed: same as degree two consistency, but most systems implement it as cursor-stability Read uncommitted: allows even uncommitted data to be read
s In many database systems (Oracle), Read Committed is the
default consistency level

has to be explicitly changed to serializable when required
set isolation level serializable
15.47
Agenda
15.48
Dealing with Deadlocks

s Deadlock Prevention (read from the book) s Deadlock detection; How do you detect a deadlock?
Wait-for graph Directed edge from Ti to Tj

Ti waiting for Tj
T2 T4 T1
T1
T2
T3 X(Z)
T4
T3
X(V) X(W) S(V) S(W) S(V) S(Z)

15.49
Suppose T4 requests lock-S(Z)....
Detecting Deadlocks
s Wait-for graph has a cycle deadlock
T2 T4 T1 T3
T2, T3, T4 are deadlocked
Build wait-for graph, check for cycle How often? - Tunable Expect many deadlocks or many xctions involved Run often to avoid aborts Else run less often to reduce overhead
15.50
Recovering from Deadlocks

s Rollback one or more xction
Which one?
Rollback the cheapest ones Cheapest ill-defined
Was it almost done? How much will it have to redo? Will it cause other rollbacks?
How far?
May only need a partial rollback

Avoid starvation
Ensure same xction not always chosen to break deadlock

Simplest mechanism:
Timeout : abort after a lengthy wait time
15.51
Concurrency Control : Summary

s 2PL, Strict 2PL,.. Ensure Conflict-Serializable schedules s Timestamp-based CC Thomas-Write Rule: can give non Conflict-serializable schedules s Optimistic CC No locking overheads but critical-section overheads s Multiple Granularity Additional intention locks to lock ancestors before we lock leaves in S or X modes. Release is always from leaf-to-root s Multi-version: fast for reads s Weaker versions Oracle default: Read Committed + Multi-version => high throughput (patented technology)
15.52

Concurrency Control II

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Concurrency Control II

Uploaded by

Copyright:

Available Formats

Concurrency Control II

Formal & commercial query languages

Database System Concepts

Concurrent xctions unaware of each other

Serial execution of transactions

equivalent to (some) serial schedules.

Database System Concepts

How to enforce serializable schedules?

s Reading Uncommitted Data (WR Conflicts, dirty reads):

Anomalies with Interleaved Execution

s Unrepeatable Reads (RW Conflicts):

R(A), W(A), R(A), W(A), C

R(B), W(B), Abort

R(A), R(A), W(A), C

Database System Concepts

W(A), W(A), W(B), C

Solution: Use appropriate CC Protocols to achieve serializable schedules

Database System Concepts

Database System Concepts

The Two-Phase Locking Protocol

transaction may obtain locks transaction may not release locks

transaction may release locks transaction may not obtain locks

Database System Concepts

Lock-Based Concurrency Control

s Strict 2PL allows only serializable schedules.

Database System Concepts

Database System Concepts

1. TS(Ti) is time Ti entered the system 2. Data item timestamps:

Timestamps -> serializability order

Database System Concepts

Database System Concepts

When Xact T wants to read Object O

Allow T to read O. Reset R-TS(O) to max(R-TS(O), TS(T))

restarts represent overheads.

When Xact T wants to Write Object O

of Q. Hence, this write operation is rejected, and T is rolled back.

When Xact T wants to Write Object O

Q; abort and restart T.

Allows non-Conflict-serializable schedules

T1 T2 R(A) W(A) Commit W(A)

Database System Concepts

How Locking works in practice

Database System Concepts

Database System Concepts

locking, and instead checking for conflicts before Xacts commit.

Database System Concepts

Optimistic CC: Kung-Robinson Model

old modified objects

Just use a timestamp.

begins. (Why then?)

Database System Concepts

Database System Concepts

Database System Concepts

s For all i and j such that Ti < Tj, check that:

Ti completes before Tj begins its Write phase + WriteSet(Ti)

Does Tj read dirty data? Does Ti overwrite Tjs writes?

s For all i and j such that Ti < Tj, check that:

Ti completes Read phase before Tj does + WriteSet(Ti) WriteSet(Ti)

Does Tj read dirty data? Does Ti overwrite Tjs writes?

Example of what validation must prevent:

Database System Concepts

Example of what validation must allow: RS(T2)={B} WS(T2)={B,D}