Concurrency Control by Validation (Section 18.9) Priyadarshini.S Cs_257_117_ch 18_18.9

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

 Scheduler keeps a record of what the active transactions are doing.  Executes in 3 phases 1. Read- reads from RS( ), computes local address 2. Validate- compares read and write sets 3. Write- writes from WS( ) reads from RS( ), computes local address

Scheduler maintains 3 states 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

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

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

TimeLine Validation T1 T2 T3 T4 A,BA,C B D D,E A,C B A,D RS WS

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

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

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

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

Timestamp Deadlock is not possible Prone to restart

Concurrency control Mechanisms Storage UtilizationDelays LocksSpace in the lock table is proportional to the number of database elements locked. Delays transactions but avoids rollbacks TimestampsSpace is needed for read and write times with every database element, neither or not it is currently accessed. Do not delay the transactions but cause them to rollback unless Interface is low ValidationSpace is used for timestamps and read or write sets for each currently active transaction, plus a few more transactions that finished after some currently active transaction began. Do not delay the transactions but cause them to rollback unless interface is low

Thank you