1. Concurrency Control by Validation
CS 255
Concurrency Control by Validation
(Section 18.9)
Priyadarshini.S

2. Validation Optimistic concurrency control
Concurrency Control assumes that conflicts between transactions are rare
Scheduler maintains record of active transactions
Does not require locking
Check for conflicts just before commit

3. Phases Read – Validate - Write
Reads from the database for the elements in its read set
ReadSet(Ti): It is a Set of objects read by Transaction Ti.
Whenever the first write to a given object is requested, a copy is made, and all subsequent writes are directed to the copy
When the transaction completes, it requests its validation and write phases

4. Phases Read – Validate - Write
Validation
Checks are made to ensure serializability is not violated
Scheduling of transactions is done by assigning transaction numbers to each transactions
There must exist a serial schedule in which transaction Ti comes before transaction Tj whenever t(i) < t(j)‏
If validation fails then the transaction is rolled back otherwise it proceeds to the third phase

5. Phases Read - Validate - Write
Writes the corresponding values for the elements in its write set
WriteSet(Ti): Set of objects where Transaction Ti has intend to write on it.
Locally written data are made global

6. Terminologies Scheduler maintains 3 states START VAL FIN
START(T), VAL(T), FIN(T)‏
START
Transactions that are started but not yet validated
VAL
Transactions that are validated but not yet finished
FIN
Transactions that are finished

7. Validation Rule 1 T1 T2 T2 starts before T1 finishes
FIN(T1) > START(T2)‏
RS(T2)  WS(T1) = 
TimeLine
Write
Validation
Read

8. Validation Rule 2 T1 T2 T2 starts before T1 finishes
FIN(T1) > VAL(T2)‏
WS(T2)  WS(T1) = 
TimeLine
Validation
Interference – Leads to
Rollback of T2
Write
No Problem

9. RS(Tj)  WS(Ti) =  FIN(Ti) > START(Tj) Rule 1 WS(Tj)  WS(Ti) = 
RS(Tj)  WS(Ti) =  FIN(Ti) > START(Tj) Rule 1 WS(Tj)  WS(Ti) =  FIN(Ti) > VAL(Tj) Rule 2 where j > i
TimeLine
Validation RS WS T1
A,B
A,C T2 B D T3 B
D,E T4
A,D
A,C

10. Validation T2 & T1 RS(T2)  WS(T1) = {B}  {A,C} = 
WS(T2)  WS(T1) = {D}  {A,C} = 
T3 & T1
RS(T3)  WS(T1) = {B}  {A,C} = 
WS(T3)  WS(T1) = {D,E}  {A,C} = 
T3 & T2
RS(T3)  WS(T2) = {B}  {D} = 
WS(T3)  WS(T2) = {D,E}  {D} = D // Rule 2 Can't be applied; FIN(T2) < VAL(T3)

11. Validation
T4 Starts before T1 and T3 finishes. So T4 has to be checked against the sets of T1 and T3
T4 & T1
RS(T4)  WS(T1) = {A,D}  {A,C} = {A}
Rule 2 can not be applied
T4 & T3
RS(T4)  WS(T3) = {A,D}  {D,E} = {D}
WS(T4)  WS(T3) = {A,C}  {D,E} = 

12. Comparison Lock Lock management overhead
Deadlock detection/resolution.
Concurrency is significantly lowered, when congested nodes are locked. Locks can not be released until the end of a transaction
Conflicts are rare. (We might get better performance by not locking, and instead checking for conflicts at commit time.)?

13. Comparison Validation
Optimistic Concurrency Control is superior to locking methods for systems where transaction conflict is highly unlikely, e.g query dominant systems.
Avoids locking overhead
Starvation: What should be done when validation repeatedly fails ?
Solution: If the concurrency control detects a starving transaction, it will be restarted, but without releasing the critical section semaphore, and transaction is run to the completion by write locking the database

14. Comparison
Timestamp
Deadlock is not possible
Prone to restart

15. Queries ???
Thank you