1 / 15

CS 255

Section 18.9 Concurrency Control by Validation Praveen AP. CS 255. Validation. Optimistic concurrency control Scheduler maintains record of active transactions Concurrency Control assumes that conflicts between transactions are rare Does not require locking

braden
Télécharger la présentation

CS 255

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Section 18.9 Concurrency Control by Validation Praveen AP CS 255

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

  3. PhasesRead – Validate - Write • Read • Reads from the database for the elements in its read set • ReadSet(Ti): 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. PhasesRead– 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. PhasesRead- Validate - Write • 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(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 • Every transaction has rs{C,D..}, ws{A,B..}

  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 TimeLine T1 T2 T2 starts before T1 finishes FIN(T1) > VAL(T2)‏ WS(T2)  WS(T1) =  Interference – Leads to Rollback of T2 Validation Write No Problem

  9. RS(Tj)  WS(Ti) =  FIN(Ti) > START(Tj) Rule 1WS(Tj)  WS(Ti) = FIN(Ti) > VAL(Tj) Rule 2 where j > i TimeLine RS Validation 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 • 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

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

  14. Comparison • Timestamp • Deadlock is not possible • Prone to restart

  15. Questions Thank you

More Related