Concurrency Control III
General Overview
 Relational model - SQL
 Formal & commercial query languages
 Functional Dependencies
 Normalization
 Physical Design
 Indexing
 Query Processing and Optimization
 Transaction Processing and CC
Validation-Based Protocol
 Execution of transaction Ti is done in three phases.
1. Read and execution phase: Ti reads all values and makes
copies to local variables (private workspace.) Ti writes only to
temporary local variables. No locking.
2. Validation phase: Transaction Ti performs a ``validation test''
to determine if local variables can be written without violating
serializability.
3. Write phase: If Ti is validated, the updates are applied to the
database; otherwise, Ti is rolled back.
 optimistic concurrency control: transaction executes fully in
the hope that all will go well during validation
Validation-Based Protocol (Cont.)
 Each transaction Ti has 3 timestamps
 Start(Ti) : the time when Ti started its execution
 Validation(Ti): the time when Ti entered its validation phase

Finish(Ti) : the time when Ti finished its write phase
 Serializability order is based on Validation(Ti).
Key idea: validation is atomic!
Validation-Based Protocol
To implement validation, system keeps the following sets:
 FIN = transactions that have finished phase 3 (and are all done)
 VAL = transactions that have successfully finished phase 2
(validation)
 For each transaction the Read and Write Sets
Example of what validation must prevent:
RS(T1)={B}
WS(T1)={B,D}
T1
start
T2
start

RS(T2)={A,B} =

WS(T2)={C}
T1
T2
validated
validated
time
T2 validation will fail!
Example of what validation must allow:
RS(T1)={B}
WS(T1)={B,D}
T1
start
T2
start

RS(T2)={A,B}
=
WS(T2)={C}
T1
T2
validated
validated
T1
finish
phase 3
T2
start
time
Another thing validation must prevent:
RS(T1)={A}
RS(T2)={A,B}
WS(T1)={D,E} WS(T2)={C,D}
T1
validated
T2
validated
finish
2
BAD: w2(D) w1T(D)
finish
T1
time
Another thing validation must allow:
RS(T1)={A}
RS(T2)={A,B}
WS(T1)={D,E} WS(T2)={C,D}
T1
T2
validated
validated
finish
finish
T1
T1
time
Validation rules for Tj:
(1) When Tj starts phase 1:
IGNORE(Tj)  FIN
(2) at Tj Validation:
if check (Tj) then
[ VAL  VAL U {Tj};
do write phase;
FIN  FIN U {Tj} ]
All transactions that either validated
or finished after the start of Tj
Check (Tj):
For Ti  VAL - IGNORE (Tj) DO
IF [ WS(Ti)  RS(Tj)   OR
Ti  FIN ] THEN RETURN false;
RETURN true;
Is this check too restrictive ?
Improving Check(Tj)
For Ti  VAL - IGNORE (Tj) DO
IF [ WS(Ti)

RS(Tj)   OR
(Ti  FIN
AND WS(Ti)  WS(Tj)  )]
THEN RETURN false;
RETURN true;
Example:
U: RS(U)={B}
WS(U)={D}
T: RS(T)={A,B}
WS(T)={A,C}
start
validate
finish
W: RS(W)={A,D}
WS(W)={A,C}
V: RS(V)={B}
WS(V)={D,E}
U,T,V successful; W abort and roll back
Overheads in Optimistic CC
 Must record read/write activity in ReadSet and WriteSet per Xact.
 Must create and destroy these sets as needed.
 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.
 Optimistic CC restarts Xacts that fail validation.
 Work done so far is wasted; requires clean-up.
``Optimistic’’ 2PL
 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.
 In contrast to previous Optimistic CC protocols, this scheme
results in Xacts being blocked, waiting for locks.
 However, no validation phase, no restarts (modulo deadlocks).
Transaction Support in SQL-92
 Each transaction has an access mode, a diagnostics size, and
an isolation level.
Isolation Level
Dirty
Read
Unrepeatable
Read
Phantom
Problem
Read Uncommitted Maybe Maybe
Maybe
Read Committed
No
Maybe
Maybe
Repeatable Reads
No
No
Maybe
Serializable
No
No
No