section 18 9 concurrency control by validation praveen ap n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CS 255 PowerPoint Presentation
Download Presentation
CS 255

Loading in 2 Seconds...

play fullscreen
1 / 15

CS 255 - PowerPoint PPT Presentation


  • 146 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CS 255' - braden


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
section 18 9 concurrency control by validation praveen ap
Section 18.9

Concurrency Control by Validation

Praveen AP

CS 255
validation
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
phases read validate write
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
phases read validate write1
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
phases read validate write2
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
terminologies
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..}
validation rule 1
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
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

rs t j ws t i fin t i start t j rule 1 ws t j ws t i fin t i val t j rule 2 where j i
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

validation1
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)
validation2
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
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
comparison1
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.)?
comparison2
Comparison
  • Timestamp
    • Deadlock is not possible
    • Prone to restart
questions
Questions

Thank you