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

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

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

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

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

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

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

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

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

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)

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} = 

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.)?

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

Comparison Timestamp Deadlock is not possible Prone to restart

Queries ??? Thank you