Concurrency control iii
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

Concurrency Control III PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on
  • Presentation posted in: General

Concurrency Control III. General Overview. Relational model - SQL Formal & commercial query languages Functional Dependencies Normalization Physical Design Indexing Query Processing and Optimization Transaction Processing and CC. Execution of transaction T i is done in three phases.

Download Presentation

Concurrency Control III

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 iii

Concurrency Control III


General overview

General Overview

  • Relational model - SQL

    • Formal & commercial query languages

  • Functional Dependencies

  • Normalization

  • Physical Design

  • Indexing

  • Query Processing and Optimization

  • Transaction Processing and CC


Validation based protocol

Execution of transaction Tiis done in three phases.

1. Read and execution phase: Tireads all values and makes copies to local variables (private workspace.) Ti writes only to temporary local variables. No locking.

2. Validation phase: Transaction Ti performs a ``validation test''

to determine if local variables can be written without violating

serializability.

3. Write phase: If Ti is validated, the updates are applied to the

database; otherwise, Ti is rolled back.

optimistic concurrency control: transaction executes fully in the hope that all will go well during validation

Validation-Based Protocol


Validation based protocol cont

Each transaction Ti has 3 timestamps

Start(Ti) : the time when Ti started its execution

Validation(Ti): the time when Ti entered its validation phase

Finish(Ti) : the time when Ti finished its write phase

Serializability order is based on Validation(Ti).

Key idea: validation is atomic!

Validation-Based Protocol (Cont.)


Validation based protocol1

Validation-Based Protocol

To implement validation, system keeps the following sets:

  • FIN = transactions that have finished phase 3 (and are all done)

  • VAL = transactions that have successfully finished phase 2 (validation)

  • For each transaction the Read and Write Sets


Example of what validation must prevent

Example of what validation must prevent:

RS(T1)={B} RS(T2)={A,B}

WS(T1)={B,D} WS(T2)={C}

= 

T1

validated

T2

validated

T1

start

T2

start

time

T2 validation will fail!


Example of what validation must allow

Example of what validation must allow:

RS(T1)={B} RS(T2)={A,B}

WS(T1)={B,D} WS(T2)={C}

= 

T1

validated

T2

validated

T1

start

T2

start

T2

start

T1

finish

phase 3

time


Another thing validation must prevent

BAD: w2(D) w1(D)

Another thing validation must prevent:

RS(T1)={A} RS(T2)={A,B}

WS(T1)={D,E} WS(T2)={C,D}

T1

validated

T2

validated

finish

T1

finish

T2

time


Another thing validation must allow

Another thing validation must allow:

RS(T1)={A} RS(T2)={A,B}

WS(T1)={D,E} WS(T2)={C,D}

T1

validated

T2

validated

finish

T1

finish

T1

time


Validation rules for t j

Validation rules for Tj:

(1) When Tj starts phase 1:

IGNORE(Tj)  FIN

(2) at Tj Validation:

if check (Tj) then

[ VAL  VAL U {Tj};

do write phase;

FIN  FIN U {Tj} ]


Concurrency control iii

All transactions that either validated

or finished after the start of Tj

Check (Tj):

For Ti  VAL - IGNORE (Tj) DO

IF [ WS(Ti)  RS(Tj)   OR

Ti  FIN ] THEN RETURN false;

RETURN true;

Is this check too restrictive ?


Improving check t j

Improving Check(Tj)

For Ti  VAL - IGNORE (Tj) DO

IF [ WS(Ti)  RS(Tj)   OR

(Ti  FIN AND WS(Ti)  WS(Tj)  )]

THEN RETURN false;

RETURN true;


Example

Example:

start

validate

finish

U: RS(U)={B}

WS(U)={D}

W: RS(W)={A,D}

WS(W)={A,C}

V: RS(V)={B}

WS(V)={D,E}

T: RS(T)={A,B}

WS(T)={A,C}

U,T,V successful; W abort and roll back


Overheads in optimistic cc

Overheads in Optimistic CC

  • Must record read/write activity in ReadSet and WriteSet per Xact.

    • Must create and destroy these sets as needed.

  • Must check for conflicts during validation, and must make validated writes ``global’’.

    • Critical section can reduce concurrency.

    • Scheme for making writes global can reduce clustering of objects.

  • Optimistic CC restarts Xacts that fail validation.

    • Work done so far is wasted; requires clean-up.


Optimistic 2pl

``Optimistic’’ 2PL

  • If desired, we can do the following:

    • Set S locks as usual.

    • Make changes to private copies of objects.

    • Obtain all X locks at end of Xact, make writes global, then release all locks.

  • In contrast to previous Optimistic CC protocols, this scheme results in Xacts being blocked, waiting for locks.

    • However, no validation phase, no restarts (modulo deadlocks).


Transaction support in sql 92

Isolation Level

DirtyRead

Unrepeatable Read

Phantom Problem

Read Uncommitted

Maybe

Maybe

Maybe

Read Committed

No

Maybe

Maybe

Repeatable Reads

No

No

Maybe

Serializable

No

No

No

Transaction Support in SQL-92

  • Each transaction has an access mode, a diagnostics size, and an isolation level.


  • Login