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

Database System Concepts

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

Database System Concepts

15.5

W(B).6 .Anomalies (Continued) s Overwriting Uncommitted Data (WW Conflicts): T1: T2: W(A). W(A). C W(B). C Solution: Use appropriate CC Protocols to achieve serializable schedules Database System Concepts 15.

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 Database System Concepts 15.7 .

the point where a transaction acquired its final lock). Database System Concepts 15. It can be proved that the transactions can be serialized in the order of their lock points (i.8 . or S/X.e. Locks can be either X. 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.The Two-Phase Locking Protocol s This is a protocol which ensures conflict-serializable schedules.

and an X (exclusive) lock on object before writing.  Has no cascading rollbacks (as locks are released only when txn completes) Database System Concepts 15. 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.9 .Lock-Based Concurrency Control s Strict Two-phase Locking (Strict 2PL) Protocol:  Each Xact must obtain a S (shared) lock on object before reading.   s Strict 2PL allows only serializable schedules.

10 .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 Database System Concepts 15.

11 . W-TS(Q): Largest timestamp of any xction that wrote Q 2. Data item timestamps: 1.Timestamp-Based Protocols s Idea:  Decide in advance ordering of xctions  Ensure concurrent schedule serializes to serial order decided  Timestamps 1. R-TS(Q): Largest timestamp of any xction that read Q  Timestamps -> serializability order Database System Concepts 15. TS(Ti) is time Ti entered the system 2.

then pi must occur before qj. Otherwise. restart violating Xact.Timestamp CC s Idea: If action pi of Xact Ti conflicts with action qj of Xact Tj. Database System Concepts 15. and TS(Ti) < TS(Tj).12 .

abort T and restart it with a new.13 . TS(T)) s Change to R-TS(O) on reads must be written to disk! This and restarts represent overheads.  Reset R-TS(O) to max(R-TS(O). writer of O.t. U writes O T reads O T start Database System Concepts U start 15. larger TS.r. (If restarted with same TS.  So. T will fail again!) s If TS(T) > W-TS(O):  Allow T to read O. this violates timestamp order of T w.When Xact T wants to read Object O s If TS(T) < W-TS(O).

T is rolled back. and W-TS(Q) is set to TS(T). s Otherwise. U reads Q T writes Q T start Database System Concepts U start 15. this write operation is rejected.When Xact T wants to Write Object O s If TS(T) < R-TS(Q). then T is attempting to write an obsolete value of Q. then the value of Q that T is producing was needed previously. and T is rolled back. the write operation is executed. write rejected. s If TS(T) < W-TS(Q). and the system assumed that that value would never be produced.14 . Hence.

allow T to write O. abort and restart T. with no intervening reads. s If TS(T) < WTS(Q).  Thomas Write Rule: We can safely ignore such outdated writes. writer of Q.r.15 . need not restart T! (T’s write is effectively followed by another write. this violates timestamp order of T w.) Allows some serializable but non conflict serializable schedules: s Else. writer of Q.t. violates timestamp order of T w.t. Allows non-Conflict-serializable schedules T1 T2 R(A) W(A) Commit W(A) Database System Concepts 15.When Xact T wants to Write Object O s If TS(T) < R-TS(Q).r.

part II Read(A).Read(A).Write(B) lock table Scheduler.l(B).Write(B) DB Database System Concepts 15.16 . part I l(A).How Locking works in practice Ti Read(A).Write(B)… Scheduler.

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 Database System Concepts 15.17 .

Disadvantages:  Lock management overhead. and instead checking for conflicts before Xacts commit.  Deadlock detection/resolution. we might be able to gain concurrency by not locking. Database System Concepts 15.Optimistic CC (Kung-Robinson) s Locking is a conservative approach in which conflicts are prevented.18 .  Lock contention for heavily used objects. s If conflicts are rare.

old modified objects Database System Concepts 15.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.19 ROOT new .  WRITE: Make local copies of changes public.

 Just use a timestamp.20 . (Why then?) s ReadSet(Ti): Set of objects read by Xact Ti.Validation s Test conditions that are sufficient to ensure that no conflict occurred. s WriteSet(Ti): Set of objects modified by Ti. Database System Concepts 15. just before validation begins. s Each Xact is assigned a numeric id. s Xact ids assigned at end of READ phase.

check that Ti completes before Tj begins. Ti R V W R Tj V W Database System Concepts 15.Test 1 s For all i and j such that Ti < Tj.21 .

Ti R V W R Tj V W Database System Concepts 15.Test 1 s For all i and j such that Ti < Tj. check that Ti completes before Tj begins.22 .

Test 2 s For all i and j such that Ti < Tj. Ti R V R W V W Tj Does Tj read dirty data? Does Ti overwrite Tj’s writes? Database System Concepts 15.23 . check that:  Ti completes before Tj begins its Write phase +  WriteSet(Ti) ReadSet(Tj) is empty.

24 . Ti R R V V W W Tj Does Tj read dirty data? Does Ti overwrite Tj’s writes? Database System Concepts 15.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.

Example of what validation must prevent: RS(T2)={B} WS(T2)={B.B} WS(T3)={C} =φ T3 validated T2 start T3 start T2 validated time Database System Concepts 15.25 .D} ∩ RS(T3)={A.

D} ∩ RS(T3)={A.B} WS(T3)={C} =φ T2 start T3 start T2 validated T3 validated T2 finish phase 3 T3 start time Database System Concepts 15.26 .Example of what validation must allow: RS(T2)={B} WS(T2)={B.

Another thing validation must prevent: RS(T2)={A} RS(T3)={A.D} T2 validated T3 validated finish BAD: w3(D) w2(D) T2 time Database System Concepts 15.27 .E} WS(T3)={C.B} WS(T2)={D.

B} WS(T2)={D.Another thing validation must allow: RS(T2)={A} RS(T3)={A.28 .D} T2 validated finish T3 validated T2 finish T2 time Database System Concepts 15.E} WS(T3)={C.

s Optimization for Read-only Xacts:  Don’t need critical section (because there is no Write phase).29 .. validation.  If Write phase is long.e. Database System Concepts 15. Nothing else goes on concurrently. and the Write phase are inside a critical section!  I. major drawback.Comments on Serial Validation s Assignment of Xact id.

Database System Concepts 15.  Must create and destroy these sets as needed. s Must check for conflicts during validation.30 .  Scheme for making writes global can reduce clustering of objects. requires clean-up. s Optimistic CC restarts Xacts that fail validation.  Work done so far is wasted.Overheads in Optimistic CC s Must record read/write activity in ReadSet and WriteSet per Xact. and must make validated writes ``global’’.  Critical section can reduce concurrency.

no validation phase.  However. we can do the following:  Set S locks as usual. Database System Concepts 15.31 .``Optimistic’’ 2PL s If desired. s In contrast to Optimistic CC as in Kung-Robinson. no restarts (modulo deadlocks). make writes global.  Obtain all X locks at end of Xact. this scheme results in Xacts being blocked. then release all locks.  Make changes to private copies of objects. waiting for locks.

32 .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 Database System Concepts 15.

33 . where the small granularities are nested within larger ones s When a transaction locks a node in the hierarchy explicitly.Multiple Granularity s Allow data items to be of various sizes and define a hierarchy of data granularities. Database contains Tables Pages Tuples Database System Concepts 15. it implicitly locks all the node's descendents in the same mode.

. tuples.Multiple Granularity s If we lock large objects (e.fields)  Need more locks  More concurrency Database System Concepts 15.g.34 .g.. Relations)  Need few locks  Low concurrency s If we lock small objects (e.

Database System Concepts 15.Example of Granularity Hierarchy The highest level in the example hierarchy is the entire database.35 . file or relation and record in that order. The levels below are of type area.

pages vs. s Shouldn’t have to decide! s Data “containers” are nested: Database contains Tables Pages Tuples Database System Concepts 15.Multiple-Granularity Locks s Hard to decide what granularity to lock (tuples vs. tables).36 .

Solution: New Lock Modes.e. 15.37 --√ IS IX S √ √ √ √ √ √ √ √ √ √ X √ IS √ IX √ S X √ √ Database System Concepts . go from specific to general (i. Xact must set “intention locks” on all its ancestors. bottom-up). but with a special protocol using new “intention” locks: y y y Before locking an item. Protocol s Allow Xacts to lock at each level. For unlock. SIX mode: Like S & IX at the same time..

 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.38 . s To get S or IS lock on a node.Multiple Granularity Lock Protocol s Each Xact starts from the root of the hierarchy. must hold IS or IX on parent node. Protocol is correct in that it is equivalent to directly setting locks at the leaf levels of the hierarchy. Database System Concepts 15.

39 .Compatibility Matrix with Intention Lock Modes s The compatibility matrix for all lock modes is: requestor IS IS IX holder IX   × × × S  ×  × × S IX  × × × × X × × × × ×     × S S IX X Database System Concepts 15.

S IS.40 . IX. S. X. IS] not necessary X. SIX [S. [SIX] none Database System Concepts 15. IX.Parent locked in Child can be locked in P C IS IX S SIX X IS.

41 . T2(IX) R1 t1 t2 T1(S) t3 t4 T2(X) Database System Concepts 15.Example T1(IS) .

using the following rules: (1) Follow multiple granularity comp function  Lock root of tree first.Multiple Granularity Locking Scheme s Transaction Ti can lock a node Q.SIX.42 .IX only if parent(Q) locked by Ti in IX. 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. whereas they are released in leaf-to-root order. Database System Concepts 15.SIX (2) Ti is two-phase (2PL) (3) Ti can unlock node Q only if none of Q’s children are locked by Ti  Observe that locks are acquired in root-to-leaf order.

2 f4. SIX [S.2 Can T2 access object f2.2 f4. IX.43 R T1(IX) t1 t2 t3 T1(X) f4. IS] not necessary X.2 in X mode? What locks will T2 get? s Parent s IS s IX s S s SIX s X Database System Concepts T1(SIX) Child IS.2 .2 f4. X. [SIX] none 15.2 f2. IX.1 f2.1 t2 t1 t2 t3 t4 f2.2 t4 f2.S.2 f4.2 f4.S IS.T1(IX) Examples R T1(IS) R t3 t4 T1(S) T1(IX) t1 T1(X) f2.1 f2.

44 .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 Database System Concepts 15.

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. Database System Concepts 15.45 . s reads never have to wait as an appropriate version is returned immediately. and return the value of the selected version. s Use timestamps to label versions. select an appropriate version of Q based on the timestamp of the transaction. s When a read(Q) operation is issued.

Cursor stability:  For reads. Degree-two consistency: differs from two-phase locking in that S-locks may be released at any time. programmer must ensure that no erroneous database state will occur 1. read. each tuple is locked.2PL and timestamp s Weaker levels of consistency 1.46 . and lock is immediately released  X-locks are held till end of transaction  Special case of degree-two consistency Database System Concepts 15.More on Consistency s We have seen thus far: Serializability -. and locks may be acquired at any time  X-locks must be held till end of transaction  Serializability is not guaranteed.

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.47 . Read Committed is the default consistency level  has to be explicitly changed to serializable when required  set isolation level serializable Database System Concepts 15. 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).

48 .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 Database System Concepts 15.

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..Dealing with Deadlocks s Deadlock Prevention (read from the book) s Deadlock detection...49 Suppose T4 requests lock-S(Z). Database System Concepts .

Tunable Expect many deadlocks or many xctions involved Run often to avoid aborts Else run less often to reduce overhead Database System Concepts 15. T4 are deadlocked •Build wait-for graph. check for cycle •How often? .Detecting Deadlocks s Wait-for graph has a cycle  deadlock T2 T4 T1 T3 T2. T3.50 .

51 .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 Database System Concepts 15.

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..52 .Concurrency Control : Summary s 2PL..  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) Database System Concepts 15.

Sign up to vote on this title
UsefulNot useful