Chapter 9 Concurrency Control

Contents Concurrency Control Concurrency Control by Locks Concurrency Control by Timestamps Concurrency Control by Validation

Concurrency Control The mechanism to preserve consistency when several transactions are executing simultaneously on DB T1T2 … Tn DB (consistency constraints)

Concepts Transaction: sequence of r i (x), w i (x) actions Schedule: a time-ordered sequence of the actions taken by one or more transactions. Serial schedule: no interleaving or mixing of actions of different transactions Serializable Schedule: Its effect on the database state is the same as that of some serial schedule

Two Transactions T1 T2 READ(A,t) READ(A,s) t:=t+100 s:=s*2 WRITE(A,t) WRITE(A,s) READ(B,t) READ(B,s) t:=t+100 s:=s*2 WRITE(B,t) WRITE(B,s)

Schedule A T1T2 Read(A); A  A+100 Write(A); Read(B); B  B+100; Write(B); Read(A);A  A  2; Write(A); Read(B);B  B  2; Write(B); AB Serial schedule in which T1 precedes T2

Schedule B T1T2 Read(A);A  A  2; Write(A); Read(B);B  B  2; Write(B); Read(A); A  A+100 Write(A); Read(B); B  B+100; Write(B); AB Serial schedule in which T2 precedes T1

Schedule C T1T2 Read(A); A  A+100 Write(A); Read(A);A  A  2; Write(A); Read(B); B  B+100; Write(B); Read(B);B  B  2; Write(B); AB A serializable, but not serial, schedule

Schedule D T1T2 Read(A); A  A+100 Write(A); Read(A);A  A  2; Write(A); Read(B);B  B  2; Write(B); Read(B); B  B+100; Write(B); AB A nonserializable schedule

Schedule E T1T2 ’ Read(A); A  A+100 Write(A); Read(A);A  A  1; Write(A); Read(B);B  B  1; Write(B); Read(B); B  B+100; Write(B); AB Same as Schedule D but with new T2’ A schedule that is serializable only because of the detailed behavior of the transactions.

Consider schedules regardless of –initial state and –transaction semantics Only look at order of read and write

A Notation for Transactions and Schedules r i (X):Transaction T i read database element X w i (X):Transaction T i write database element X For example T 1 :r 1 (A);W 1 (A);r 1 (B);W 1 (B) T 2 : r 2 (A);W 2 (A);r 2 (B);W 2 (B) A Schedule: r 1 (A);W 1 (A); r 2 (A);W 2 (A) ;r 1 (B);W 1 (B) ;r 2 (B);W 2 (B)

Conflicts Two actions of the same transaction, e.g ri(X);wi(X),conflict. Two writes of the same database element by different transactions conflict. A read and a write of the same database element by different transactions conflict, e.g.,ri(X);wj(X), conflict. Conflicting actions: r1( A ) r 1(A) w 2(A) w 1(A) w1 (A) w 2(A) r 1(A) w 2(A) To summarize : any two actions of different transactions may be swapped in order,unless  They involve the same database element, and  At least one is write.

Conflict-Serializability 1.S 1, S 2 are conflict equivalent schedules if S 1 can be transformed into S 2 by a series of swaps on non-conflicting actions. 2.A schedule is conflict serializable if it is conflict equivalent to some serial schedule.

Sc ’ =r 1 (A)w 1 (A) r 1 (B)w 1 (B)r 2 (A)w 2 (A)r 2 (B)w 2 (B) T 1 T 2 Example: Sc=r 1 (A)w 1 (A)r 2 (A)w 2 (A)r 1 (B)w 1 (B)r 2 (B)w 2 (B)

Example :Consider the schedule r 1 (A);W 1 (A); r 2 (A);W 2 (A) ;r 1 (B);W 1 (B) ;r 2 (B);W 2 (B) r 1 (A);W 1 (A); r 2 (A); r 1 (B); W 2 (A);W 1 (B) ;r 2 (B);W 2 (B) r 1 (A);W 1 (A); r 1 (B); r 2 (A); W 2 (A);W 1 (B) ;r 2 (B);W 2 (B) r 1 (A);W 1 (A); r 1 (B); r 2 (A); W 1 (B);W 2 (A) ; r 2 (B);W 2 (B) r 1 (A);W 1 (A); r 1 (B); W 1 (B);r 2 (A); W 2 (A) ; r 2 (B);W 2 (B) Converting a conflict-serializable schedule to a serial schedule by swaps of adjacent actions

However, for Sd: Sd=r 1 (A)w 1 (A)r 2 (A)w 2 (A) r 2 (B)w 2 (B)r 1 (B)w 1 (B)

Testing Conflict-Serializability by Precedence Graphs Precedence graph P(S) (S is schedule) Nodes: transactions in S Arcs: Ti  Tj if Ti < S Tj, that is - p i (A), q j (A) are actions in S - p i is ahead of q j in S - at least one of p i, q j is a write 1.If there are any cycles, S is not conflict-serializable. 2.Otherwise, S is conflict-serializable

Sc=r 1 (A)w 1 (A)r 2 (A)w 2 (A)r 1 (B)w 1 (B)r 2 (B)w 2 (B) T 1  T 2 T 1  T 2  no cycles  Sc is “ equivalent ” to a serial schedule (in this case T 1,T 2 )

For example, the following schedule S involves 3 transactions T1,T2 andT3. S:r 2 (A);r 1 (B);w 2 (A);r 3 (A);w 1 (B);w 3 (A);r 2 (B);w 2 (B) We can find :  T2<sT3  T1<sT2 The precedence graph for the schedule S is : 1 23 The conflict-equivalent serial schedule : (T1,T2,T3)

For example consider the schedule S1:r 2 (A);r 1 (B);w 2 (A);r 2 (B);r 3 (A);w 1 (B);w 3 (A);W 2 (B) We can find that:  T2 < sT3  T1<sT2  T2<sT We conclude that S1 is not conflict-serializable.

Lemma S 1, S 2 conflict equivalent  P(S 1 )=P(S 2 ) Proof: Assume P(S 1 )  P(S 2 )   T i : T i  T j in S 1 and not in S 2  S 1 = … p i (A)... q j (A) … p i, q j S 2 = … q j (A) … p i (A)... conflict  S 1, S 2 not conflict equivalent

Note: P(S 1 )=P(S 2 )  S 1, S 2 conflict equivalent For example: S 1 =w 1 (A) r 2 (A) w 2 (B) r 1 (B) S 2 =r 2 (A) w 1 (A) r 1 (B) w 2 (B)

Theorem P(S 1 ) acyclic  S 1 conflict serializable (  ) Assume S 1 is conflict serializable  S s : S s, S 1 conflict equivalent (S s means the serial schedule of all the transactions in S 1 ).  P(S s ) = P(S 1 )  P(S 1 ) acyclic since P(S s ) is acyclic

(  ) Assume P(S 1 ) is acyclic Transform S 1 as follows: (1) Take T 1 to be transaction with no entry arcs (2) Move all T 1 actions to the front S 1 = ……. q j (A) ……. p 1 (A) ….. (3) we now have S 1 = (4) repeat above steps to serialize rest! T 1 T 2 T 3 T 4 Theorem P(S 1 ) acyclic  S 1 conflict serializable

Two new actions: lock (exclusive):l i (A) unlock:u i (A) scheduler T 1 T 2 lock table Enforcing serializability by locks

Legality of Schedules S = …….. l i (A) ………... u i (A) ……... no l j (A) S1 = l 1 (A)l 1 (B)r 1 (A)w 1 (B)l 2 (B)u 1 (A)u 1 (B) r 2 (B)w 2 (B)u 2 (B)l 3 (B)r 3 (B)u 3 (B)

Schedule F T1 T2 l 1 (A);Read(A) A A+100;Write(A);u 1 (A) l 2 (A);Read(A) A Ax2;Write(A);u 2 (A) l 2 (B);Read(B) B Bx2;Write(B);u 2 (B) l 1 (B);Read(B) B B+100;Write(B);u 1 (B)

Schedule F T1 T l 1 (A);Read(A) A A+100;Write(A);u 1 (A) 125 l 2 (A);Read(A) A Ax2;Write(A);u 2 (A) 250 l 2 (B);Read(B) B Bx2;Write(B);u 2 (B) 50 l 1 (B);Read(B) B B+100;Write(B);u 1 (B) A B A legal schedule of consistent transaction, but it is not serializable

Two phase locking (2PL) for transactions T i = ……. l i (A) ………... u i (A) ……... no unlocks no locks In every transaction, all lock requests precede all unlock requests.

# locks held by Ti Time Growing Shrinking Phase 1 Phase 2

Schedule G delayed

Schedule G delayed

Schedule G delayed The locking scheduler delays requests that result in an illegal schedule

Locking Systems With Several Lock Mode Shared and Exclusive Locks Upgrading Locks Update locks Increment locks

Shared and Exclusive Locks  When we want to read X, we need to get the shared or exclusive lock on X, but we prefer the former  When we want to write X, we need to get the exclusive lock on X  Some expressions  sli(X): transaction Ti requests a shared lock on database element X  xli(X): transaction Ti requests an exclusive lock on database element X  ui(X): Ti unlocks X

Shared locks So far: S =...l 1 (A) r 1 (A) u 1 (A) … l 2 (A) r 2 (A) u 2 (A) … Do not conflict Instead: S=... ls 1 (A) r 1 (A) ls 2 (A) r 2 (A) …. us 1 (A) us 2 (A) Exclusive Locks Transactions that read and write the same objects. T i =...l-X 1 (A) … r 1 (A)... w 1 (A)... u(A) …

Three Requirements of a Shared/Exclusive Lock System 1.Consistency of transactions 2.Two-phase locking of transactions 3.Legality of schedules

Consistency of Transactions T i =... l-S 1 (A) … r 1 (A) … u 1 (A) … T i =... l-X 1 (A) … w 1 (A) … u 1 (A) …

Two-phase locking of transactions No action sl i (X) or xl i (X) can be preceded by an action u i

Legality of Schedules S =....l-S i (A) … … u i (A) … no l-X j (A) S =... l-X i (A) … … u i (A) … no l-X j (A) no l-S j (A)

For example :Let us examine a possible schedule of the following two transactions,using shared and exclusive locks: 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) T1 T2 sl1(A);r1(A); sl2(A);r2(A); sl2(B);r2(B); xl1(B) Denied u2(A);u2(B) xl1(B);r1(B);w1(B); u1(A);u1(B); Notice that the schedule is conflict- serializable, the conflict- equivalent serial order is (T2,T1)

The compatibility matrix for shared and exclusive locks Lock requested S X Lock held in mode SXSX Yes No No

Upgrading Locks A transaction T that wants to read and write a new value of X first take a shared lock on X,and only later,when T is ready to write the new value,upgrade the lock to exclusive ui(X) releases all locks on X held by transaction Ti

Upgrade (E.g., need to read, but don ’ t know if will write … ) T i =... l-S 1 (A) … r 1 (A)... l-X 1 (A) … w 1 (A)...u1(A) … Think of - Get 2nd lock on A, or - Drop S, get X lock

Upgrading locks allows more concurrent operation 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 T2 sl1(A);r1(A); sl2(A);r2(A); sl2(B);r2(B); sl1(B);r1(B); xl1(B) Denied u2(A);u2(B) xl1(B);w1(B) u1(A);u2(B)

Indiscriminate use of upgrading introduces a new source of potentially serious source of deadlocks T1 T2 sl1(A) sl2(A) Xl1(A) Denied xl2(A)Denied

Solution If T i wants to read A and knows it may later want to write A, it requests update lock (not shared)

Update Locks The update lock can be upgraded to a write lock later; A read lock cannot be upgraded We can grant an update lock on X when there are already shared locks on X,but once there is an update lock on X we prevent additional locks of any kind from being taken on X

Compatibility matrix for shared, exclusive,and update locks S X U SXUSXU Yes No Yes No No No

The update locks can fix the deadlock problem. T1:ul1(A);r1(A);xl1(A);w1(A);u1(A); T2:ul2(A);r2(A);xl2(A);w2(A);u2(A); T1 T2 ul1(A);r1(A); ul2(A)Denied xl1(A);w1(A);u1(A); ul2(A);r2(A); xl2(A);w2(A);u2(A)

Increment Locks Atomic increment action: IN i (A) {Read(A); A  A+k; Write(A)} IN i (A), IN j (A) do not conflict! A=7 A=5A=17 A=15 IN i (A) +2 IN j (A) +10 IN j (A) +2 IN i (A)

 A consistent transaction can only have increment action on X if it holds an increment lock on X at the time. An increment lock does not enable either read or write actions  In a legal schedule,any number of transactions can hold an increment lock on X at any time  The action inc i (X) conflicts with both r j (X) and w j (X), but does not conflict with inc j (X)

Compatibility matrix for shared,exclusive,and increment locks S X I SXISXI Yes No No No No No No No.Yes

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 T2 sl1(A);r1(A); sl2(A);r2(A); il2(B);inc2(B); il1(B);inc1(B); u2(A);u2(B); u1(A);u1(B) S: r1(A);r2(A);inc2(B);inc1(B) r1(A);r2(A); inc1(B);inc2(B) r1(A); inc1(B); r2(A); inc2(B)

Ti Read(A),Write(B) l(A),Read(A),l(B),Write(B) … Read(A),Write(B) Scheduler, part I Scheduler, part II DB lock table Locking System

Lock table Conceptually A  B C ... Lock info for B Lock info for C If null, object is unlocked Every possible object

But use hash table: A If an object not found in hash table, it is unlocked Lock info for A A... H

Lock info for A - example tran mode wait? Nxt T_link Object:A Group mode:U Waiting:yes List: T1 S no T2 U no T3X yes  To other T3 records The group mode is a summary of the most stringent conditions that a transaction requesting a new lock on A.

Handling Lock Requests If there is no lock-table entry for A, the entry is created and the request is granted If the lock-table entry for A exists –If the group mode is “update”or “exclusive”,then the request is denied –If the group mode is “shared”,then another shared or update lock can be granted,and we need to modify the group mode

Handling Unlocks Delete T’s entry on the list for A Modify the group mode –If the lock held by T is not the same as the group mode,then we need not change the group mode –Else we may have to examine the entire list to find the new group mode If the value of waiting is “yes”, then we need to grant one or more locks from the list of requested locks –First-come –first –served –Priority to shared locks –Priority to upgrading

What are the objects we lock? ? Relation A Relation B... Tuple A Tuple B Tuple C... Disk block A Disk block B... DB

Locking works in any case, but should we choose small or large objects? If we lock large objects (e.g., Relations) –Need few locks –Low concurrency If we lock small objects (e.g., tuples, fields) –Need more locks –More concurrency

Managing Hierarchies of Database Elements A hierarchy of lockable elements, e.g. relations  blocks  tuples The data that is itself organized in a tree e.g. B-Tree R1 B1B2 B3 t1 t2t3 Relations Blocks Tuples

hall Stall 1Stall 2Stall 3Stall 4 restroom

Warning Locks IS: the intention to obtain a shared lock on a subelement IX: the intention to obtain a exclusive lock on a subelement

The rules of the warning protocol (1) To place an ordinary S or X on any element,we must begin at the root of the hierarchy (2) If we are at the element that we want to lock, we need to look no further, we request an S or X lock on that element (3) If the element we wish to lock is further down the hierarchy, then we place a warning at this node. When the lock on the current node is granted, we proceed to the appropriate child. We repeat step (2) or step(3) until we reach the desired node

Compatibility matrix for shared, exclusive,and intention locks Yes Yes Yes No Yes Yes No No Yes No No No IS IX S X IS IX S X

EXAMPLE 17: Consider the relation Movie(title,year,length,studioName) Set a lock on the entire relation and locks on individual tuples. T1: SELECT * FROM Movie WHERE title=‘King Kong’ T2: UPDATE Movie SET year=1939 WHERE title=‘Gone With the Wind’

T1-IS T2-IX Movies King Kong T1-S King Kong T1-S Gone With the Wind T2-X

Handling Insertions Correctly The phantom problem: We can only lock existing items; there is no easy way to lock database elements that do not exist but might later be inserted

Example: relation R (E#,name, … ) constraint: E# is key suppose use tuple locking RE#Name …. o155Smith o275Jones

T 1 : Insert into R T 2 : Insert into R T 1 T 2 S 1 (o 1 ) S 2 (o 1 ) S 1 (o 2 ) S 2 (o 2 ) Check Constraint Insert o 3 [99,Gore,..] Insert o 4 [99,Bush,..]...

Solution Use multiple granularity tree Before insert of node Q, lock parent(Q) in X mode R1 t1t1 t2t2 t3t3

Back to example T 1 : Insert T 2 : Insert T 1 T 2 X 1 (R) Check constraint Insert U(R) X 2 (R) Check constraint Oops! e# = 99 already in R! delayed

The Motivation for Tree-Based Locking If using two-phase locking, concurrent use of the B-tree is almost impossible, because transaction can not unlock the root until it has acquired all the locks it need.

Example A B C D EF All objects accessed through root, following pointers T 1 lock  Can we release A lock if we no longer need A??

Idea: traverse like “ Monkey Bars ” A B C D EF T 1 lock

Why does this work? Assume all T i start at root; exclusive lock T i  T j  T i locks root before T j Actually works if we don ’ t always start at root Root Q T i  T j

Rules: tree protocol (exclusive locks) (1) First lock by T i may be on any item (2) After that, item Q can be locked by T i only if parent(Q) locked by T i (3) Items may be unlocked at any time (4) After T i unlocks Q, it cannot relock Q

Three transactions following the tree protocol T1 T2 T3 l1(A);r1(A) l1(B);r1(B) l1(C);r1(C) w1(A);u1(A) L1(D);r1(D) W1(B);u1(B) l2(B);r2(B) l3(E);r3(E); w1(D);u1(D) w1(C);u1(C) l2(E)Denied l3(F);r3(F) w3(F);u3(F) l3(G);r3(G) w3(E);u3(E) l2(E);r2(E) w3(G);u3(G) w2(B);u2(B) w2(E);u2(E) A B C DE F G T1:A,B,C,D not 2PL T2:B,E 2PL T3:E,F,G not 2PL

Ti<sTj: In schedule S,the transaction Ti and Tj lock a node in common,and Ti locks the node first

In the schedule S of the example, we find that T1<sT2 (B) T3<sT2 (E) The equivalent serial schedule is (T1,T3,T2) or (T3,T1,T2)

Concurrency Control by Timestamps Timestamping Validation  Both of them are optimistic The remedy method : rollback and restart  All locking methods are pessimistic, The remedy method: delay, not abort

Timestamps Timestamp of T (TS(T)): The time that a transaction T notifies the scheduler that it is beginning Approaches to generating timestamps –Use the system clock –Maintain a counter

Timestamps Each database element X is associated with two timestamps and an additional bit: –RT(X): the highest timestamp of a transaction that has read X –WT(X): the highest timestamp of a transaction that has written X –C(X): the commit bit for X, which is true if and only if the most recent transaction to write X has already committed.

The scheduler assumes that the timestamp order of transactions is also the serial order in which they must appear to execute

Two Kinds of Unrealizable Behaviors Read too late Write too late T startU start U writes XT reads X T startU start U reads XT writes X Read too lateWrite too late

Problems With Dirty Data U writes X T reads X U startT startU abort

T startU start U writes XT writes X T commits U aborts A potential problem with thomas write rule Thomas write rule: writes can be skipped when a write with a later write-time is already in place. Solution: when write(X), set C(X) to be false and make a copy of the old value of X and its previous WT(X).

The Rules for Timestamp-Based Scheduling For read request, see whether it is too late. For write request, see whether it is too late. For commit request, set commit bit. For abort or roll back request, resume the other transaction.

Suppose the scheduler receives a request r T (X) –If TS(T)≥WT(X), the read is physically realizable If c(X) is true,grant the request.If TS(T)>RT(X), set RT(X):=TS(T); otherwise so not change RT(X) If c(X) is false,delay T until c(X) becomes true or the transaction that wrote X aborts –If TS(T)<WT(X), read too late. Rollback T;

Suppose the scheduler receives a request w T (X) –If TS(T) ≥RT(X) and TS(T) ≥WT(X), the write is physically realizable and must be performed. Write the new value for X Set WT(X):=TS(T),and Set c(X):=false –If TS(T) ≥RT(X),but TS(T) <WT(X), follow Thomas write rule. –If TS(T) <RT(X),then write too late

Suppose the scheduler receives a request to commit T. (1) Set c(X):=true for all database elements X written by T. (2) Resume any transactions that are waiting for T to be committed Suppose the scheduler request to abort T or decides to rollback T as in 1b or 2c.Then any transaction that was waiting on an element X that T wrote must repeat its attempt to read or write,and see whether the action is now legal after the aborted transaction’s writes are cancelled

T1 T2 T3 A B C RT=0 RT=0 RT=0 WT=0 WT=0 WT=0 r1(B) RT=200 r2(A) RT=150 r3(C) RT=175 w1(B) WT=200 w1(A) WT=200 w2(C) Abort w3(A) Three transactions executing under a timestamp-based scheduler

Multiversion Timestamps Maintain old versions of database elements in addition to the current version.

T1 T2 T3 T4 A RT=0 WT=0 r1(A) RT=150 w1(A) WT=150 r2(A) RT=200 w2(A) WT=200 r3(A) Abort r4(A) RT=225 T3 must abort because it cannot access an old value of A

Execution of transactions using multiversion concurrency control T1 T2 T3 T4 A 0 A 150 A r1(A) read W1(A) create r2(A) read w2(A) create r3(A) read r4(A) read

Timestamps and Locking In low-conflict situations, timestamp performs better In high-conflict situations, locking performs better.

Concurrency Control by Validation Allow transactions to access data without locks Check the serializability at the appropriate time.

Validation Transactions have 3 phases: (1) Read –all DB values read –writes to temporary storage –no locking (2) Validate –check if schedule so far is serializable (3) Write –If validate ok, write to DB

Key idea Make validation atomic If T 1, T 2, T 3, … is validation order, then resulting schedule will be conflict equivalent to S s = T 1 T 2 T 3...

To implement validation, system keeps three sets: START=transactions that have started, but not yet completed VAL = transactions that have successfully finished phase 2 (validation) FIN = transactions that have finished phase 3 (and are all done)

The Validation Rules T reads X U writes X U start T start U validated T validating T cannot validate if an earlier transaction is now writing something that T should have read 11

Example of what validation must prevent: RS(T 2 )={B} RS(T 3 )={A,B} WS(T 2 )={B,D} WS(T 3 )={C} time T 2 start T 2 validated T 3 validated T 3 start  =  RS(T): the set of database elements T reads WS(T): the set of database elements T writes

T 2 finish phase 3 Example of what validation must prevent: RS(T 2 )={B} RS(T 3 )={A,B} WS(T 2 )={B,D} WS(T 3 )={C} time T 2 start T 2 validated T 3 validated T 3 start  =  allow T 3 start

T writes X U writes X U validatedT validating U finish T cannot validate if it could then write something ahead of an earlier transaction 22

Another thing validation must prevent: RS(T 2 )={A} RS(T 3 )={A,B} WS(T 2 )={D,E} WS(T 3 )={C,D} time T 2 validated T 3 validated finish T 2 BAD: w 3 (D) w 2 (D)

finish T 2 Another thing validation must prevent: RS(T 2 )={A} RS(T 3 )={A,B} WS(T 2 )={D,E} WS(T 3 )={C,D} time T 2 validated T 3 validated allow finish T 2

For validating a transaction T Compare RS(T) with WS(U) and check that RS(T)  WS(U)=  for any U that did not finish before T started,i.e.,if FIN(U)>START(T) Compare WS(T) with WS(U) and check that WS(T)  WS(U)=  for any U that did not finish before T VALIDATED,i.e.,if FIN(U)>VAL(T)

Example: T: RS(T)={A,B} WS(T)={A,C} V: RS(V)={B} WS(V)={D,E} U: RS(U)={B} WS(U)={D} W: RS(W)={A,D} WS(W)={A,C} start validate finish

 Validation of U : it validates successfully  Validation of T:,  RS(T)  WS(U)={A,B}  {D}=   WS(T)  WS(U)={A,C}  {D}=   Validation of V  RS(V)  WS(T)={B}  {A,C}=   WS(V)  WS(T)={D,E}  {A,C}=   RS(V)  WS(U)={B}  {D}=   Validation of W  RS(W)  WS(T)={A,D}  {A,C}= {A}  RS(W)  WS(V)={A,D}  {D,E}= {D}  WS(W)  WS(V)={A,C}  {D,E}=  W is rolled back

Comparison of Three Concurrency- Control Mechanisms Storage utilization –Locks:space in the lock table is proportional to the number of database elements locked –Timestamps: Store read- and write-times in a table analogous to a lock table –Validation:Space is used for timestamps and read/write sets for each currently active transaction The ability to complete without delay –Locking delays but avoids rollbacks, timestamps and validation do not delay, but cause them to rollback

Summary Have studied C.C. mechanisms used in practice - 2 PL - Multiple granularity - Tree (index) protocols - Timestamp - Validation