Concurrency control by validation 18 9
Download
1 / 12

Concurrency Control by Validation (18.9) - PowerPoint PPT Presentation


  • 108 Views
  • Uploaded on

Concurrency Control by Validation (18.9). By: Pushkar Marathe Id: 217. Agenda. Overview Architecture of the scheduler Validation rules Example Comparison of concurrency control mechanisms. Overview. Type of optimistic concurrency control.

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 ' Concurrency Control by Validation (18.9)' - allistair-bates


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
Concurrency control by validation 18 9

Concurrency Control by Validation(18.9)

By:

Pushkar Marathe

Id: 217


Agenda
Agenda

  • Overview

  • Architecture of the scheduler

  • Validation rules

  • Example

  • Comparison of concurrency control mechanisms


Overview
Overview

  • Type of optimistic concurrency control.

  • Scheduler keeps a record of transactions rather than timestamps.

  • Validation phase before writing values into database.


Architecture
Architecture

  • Scheduler should know the read and write sets for each transaction.

  • Three phases of transactions:

    • Read: Reads from database to read set.

    • Validate: Validates by comparing the read and write sets with other transactions.

    • Write: Writes from write set to database.

  • Serial order is maintained based on which the scheduler decides whether to validate or not.


    • To support the decision of validating three sets are maintained:

      • START: Set of all active transactions that are not validated.

      • VAL: Set of all transactions that are validated and are still active.

      • FIN: Set of all transactions that have finished execution. For these the scheduler records START(T),VAL(T),FIN(T).


    Validation rules

    T reads X maintained:

    U writes X

    T start

    T validating

    U start

    U validated

    Validation Rules

    • Suppose there is a transaction U such that:

      • U is in VAL or FIN; that is, U has validated.

      • FIN(U)>START(T); that is, U did not finish before T started.

      • RS(T) Π WS(U) is not empty; in particular, let it contain database element X.

    Figure 1



    T reads X sure that T got to read U’s value we need to rollback T to avoid a risk that the actions of T and U will be consistent with the serial order.

    U writes X

    T validating

    U finish

    U validating

    • Suppose there is a transaction U such that:

      • U is in VAL or FIN; that is, U has validated.

      • FIN(U)>START(T); that is, U did not finish before T started.

      • RS(T) Π WS(U) is not empty; in particular, let it contain database element X.


    T and U both write values of X and if we validate T then it will write X before U. Here also we rollback T so that order is not violated.


    Comparison of three concurrency control mechanisms
    Comparison of three concurrency-control Mechanisms will write X before U. Here also we rollback T so that order is not violated.

    Storage Utilization

    • Locks : Space in lock table proportional to number of database elements locked

    • Timestamps : Space proportional to database elements that have been accessed recently.

    • Validation : Space proportional to currently active transactions and some transactions that finished just some time before the current started.


    • We can also compare based on ability of transactions to complete without delay.

      • Locking delays transactions but avoids rollback.

      • If interface is low, then neither timestamps nor validations will cause rollbacks.

      • When rollback necessary timestamps can catch problems earlier than validation.


    THANK YOU complete without delay.


    ad