Temple university cis dept cis616 principles of data management
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

Temple University – CIS Dept. CIS616– Principles of Data Management PowerPoint PPT Presentation


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

Temple University – CIS Dept. CIS616– Principles of Data Management . V. Megalooikonomou Concurrency Control – Deadlocks (based on slides by C. Faloutsos at CMU and on notes by Silberchatz,Korth, and Sudarshan). Isolation - concurrency control. serializability <-> correctness

Download Presentation

Temple University – CIS Dept. CIS616– Principles of Data Management

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


Temple university cis dept cis616 principles of data management

Temple University – CIS Dept.CIS616– Principles of Data Management

V. Megalooikonomou

Concurrency Control – Deadlocks

(based on slides by C. Faloutsos at CMU and on notes by Silberchatz,Korth, and Sudarshan)


Isolation concurrency control

Isolation - concurrency control

  • serializability <-> correctness

    • precedence graph

  • automatically correct interleavings:

    • locks + protocol (2PL, 2PLC)

    • but: deadlocks!


Deadlocks

Deadlocks

  • detection

  • handling

  • (prevention)


Deadlock detection

Deadlock detection

T1 T2 lock manager

L(A) Yes

L(B) Yes

...

L(B) No

<waits>

L(A) No

time

DEADLOCK


Algorithm for deadlock detection

Algorithm for deadlock detection?

  • wait-for graph:

  • nodes  transactions

  • arcs  Tsource waits for Tsink

  • if cycle, then deadlock!

  • Must invoke a deadlock-detection algorithm periodically to look for cycles


Example

Example

T1 T2 lock manager

L(A) Yes

L(B) Yes

...

L(B) No

<waits>

L(A) No

time

for ‘B’

T1

T2

‘A’

‘B’

for ‘A’


Another example

T1

T2

T4

T3

Another example

  • is there a deadlock?

  • if yes, which xacts are involved?


Another example1

T1

T2

T4

T3

Another example

  • now, is there a deadlock?

  • if yes, which xacts are involved?


Deadlock detection1

Deadlock detection

  • how often should we run the algorithm?

  • how many transactions are typically involved?


Deadlock handling

T1

T2

T4

T3

Deadlock handling

  • Q: what to do?


Deadlock handling1

T1

T2

T4

T3

Deadlock handling

  • Q0: what to do?

    • A: select a ‘victim’ & ‘rollback’

  • Q1: which/how to choose?


Deadlock handling2

T1

T2

T4

T3

Deadlock handling

  • Q1: which/how to choose?

    • A1.1: by age

    • A1.2: by progress

    • A1.3: by # items locked already...

    • A1.4: by # xacts to rollback

  • Q2: How far to rollback?


Deadlock handling3

T1

T2

T4

T3

Deadlock handling

  • Q2: How far to rollback?

    • A2.1: completely

    • A2.2: minimally

  • Q3: Starvation??


Deadlock handling4

T1

T2

T4

T3

Deadlock handling

  • Q3: Starvation??

  • A3.1: include #rollbacks in victim selection criterion


Sql statement

SQL statement

  • usually, conc. control is transparent to the user, but

  • LOCK <table-name> [EXCLUSIVE|SHARED]


Concurrency control conclusions

Concurrency control - conclusions

  • serializability <-> correctness

  • automatically correct interleavings:

    • locks + protocol (2PL, 2PLC, ...)

    • deadlock detection + handling


Conclusions

Conclusions

2PL schedules

serializable schedules

serializable schedules

2PLC

serial sch’s


  • Login