optimistic concurrency control

24
6.830 Lecture 14 Two-phase Locking Recap Optimistic Concurrency Control 10/28/2015

Upload: oliver-cameron

Post on 01-Jan-2016

72 views

Category:

Documents


0 download

DESCRIPTION

Optimistic Concurrency Control. 6.830 / 6.814 Lecture 14 10/27/2014. OCC Runtime. twrite ( n,i,v ): if n not in write_set // never written, make copy m = copy(n); copies[n] = m; write_set = write_set union {n}; write(copies[n], i , v))) tread ( n,i ): - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Optimistic Concurrency Control

6.830 Lecture 14Two-phase Locking Recap

Optimistic Concurrency Control

10/28/2015

Page 2: Optimistic Concurrency Control
Page 3: Optimistic Concurrency Control

Basic Two Phase Locking Protocol• Before every read, acquire a shared lock

• Before every write, acquire an exclusive lock (or "upgrade") a shared to an exclusive lock

• Only release locks after all locks have been acquired

• Lock point = point when all locks are acquired• Transaction can run to completion• Will be serialized after any conflicting transactions that already

completed, and before any other conflict transaction

Page 4: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Page 5: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Page 6: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Page 7: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Page 8: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Page 9: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Release X?

If T1 releases X at this point, T2 could update X and Y before T1, resulting in a non-serial schedule.

Page 10: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Release X? Slock Y

Page 11: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Release X? Slock Y

Page 12: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Release X? Slock Y

Release X

Slock X

Page 13: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Release X? Slock Y

Release X

Slock X

Read X

Write X

Page 14: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Release X? Slock Y

Release X

Slock X

Read X

Write X

Acq Y?

Page 15: Optimistic Concurrency Control

Example ( 2 x RX WX RY WY )T1 T2

Slock X

Read X

Xlock X

Write X

Release X? Slock Y

Release X

Slock X

Read X

Write X

Acq Y? (Waits for T1)

Page 16: Optimistic Concurrency Control

Two Problems

• Cascading Aborts• Deadlocks

Page 17: Optimistic Concurrency Control

Rigorous Two Phase Locking Protocol• Before every read, acquire a shared lock

• Before every write, acquire an exclusive lock (or "upgrade") a shared to an exclusive lock

• Release locks only after the transaction commits

• Ensures cascadeless-ness, and that commit order = serialization order

Page 18: Optimistic Concurrency Control

Deadlock Detection & Prevention• Detection techniques• Look for a cycle in waits-for graph• Or use a timeout

• Once a deadlock is found, kill one of the deadlock transactions• Release its locks and “roll back”

• Why is deadlock avoidance not possible?

Page 19: Optimistic Concurrency Control

OCC Write

twrite(object,value): if object not in write_set: // never written, make copy m = read(object) copies[object] = m write_set = write_set U {object} write(copies[object], value)

Page 20: Optimistic Concurrency Control

OCC Read

tread(object): read_set = read_set U {object}; if object in write_set:

return read(copies[object]); else:

return read(object);

Page 21: Optimistic Concurrency Control

Validation Rules

When Tj completes its read phase, require that for all Ti < Tj, one of the following conditions must be true for validation to succeed (Tj to commit):

1) Ti completes its write phase before Tj starts its read phase2) W(Ti) does not intersect R(Tj), and Ti completes its write phase before

Tj starts its write phase. 3) W(Ti) does not intersect R(Tj) or W(Tj), and Ti completes its read

phase before Tj completes its read phase. 4) W(Ti) does not intersect R(Tj) or W(Tj), and W(Tj) does not intersect

R(Ti) [no conflicts]

These rules will ensure serializability, with Tj being ordered after Ti with respect to conflicts

Page 22: Optimistic Concurrency Control

Condition 1

Ti completes its write phase before Tj starts its read phase

Don't overlap at all.

Read Validate WriteTi

Read Validate WriteTj

Time

Page 23: Optimistic Concurrency Control

Condition 2

W(Ti) does not intersect R(Tj), and Ti completes its write phase before Tj starts its write phase.

Tj doesn’t read anything Ti wrote.Anything Tj wrote that Ti also wrote will be installed afterwards. Anything Ti read will not reflect Tjs writes

Read Validate WriteTi

Read Validate WriteTj

Time

W(Ti) ∩ R(Tj) = { } R(Ti) ∩ W(Tj) ≠ { } W(Ti) ∩ W(Tj) ≠ { }

Page 24: Optimistic Concurrency Control

Condition 3W(Ti) does not intersect R(Tj) or W(Tj), and Ti completes its read phase before Tj completes its read phase.

Tj doesn’t read or write anything Ti wrote (but Ti may read something Tj writes).

Ti definitely won’t see any of Tj’s writes, because it finishes reading before Tj starts validation, so Ti ordered before Tj.

Ti will always complete its read phase before Tj b/c timestamps assigned after read phase

Read Validate WriteTi

Read Validate WriteTj

Time

W(Ti) ∩ R(Tj) = { } R(Ti) ∩ W(Tj) ≠ { } W(Ti) ∩ W(Tj) = { }