1 / 15

Serializable Isolation for Snapshot Databases by Cahill, R öhm , and Fekete

Serializable Isolation for Snapshot Databases by Cahill, R öhm , and Fekete. Presented by Dr. Greg Speegle. Snapshot isolation ( sI ). Concurrency Control Multiple Versions Version number timestamp of writing transaction Read last committed value Ex. w0(x)c0R1(x)W1(x)R2(x)

jetta
Download Presentation

Serializable Isolation for Snapshot Databases by Cahill, R öhm , and Fekete

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Serializable Isolation for Snapshot Databases byCahill, Röhm, and Fekete Presented by Dr. Greg Speegle

  2. Snapshot isolation (sI) • Concurrency Control • Multiple Versions • Version number timestamp of writing transaction • Read last committed value • Ex. w0(x)c0R1(x)W1(x)R2(x) • First committer wins • Ex. w0(x)c0R1(x)W1(x)R2(x)W2(x)c2c1 => abort T1 • rw conflicts • Ti reads x concurrent with Tj writes x • Popular in commercial databases

  3. SI vs 2pl • Lower overhead • No read locks • No blocking between reads and writes • Ex: R1(x)R2(x)W1(x) • Non-serializable schedules allowed • R1(x)R1(y)R2(x)R2(y)W1(x)W2(y)c1c2 • R1(y) < W2(y) => T1->T2 • R2(x) < W1(x) => T2->T1 • Write skew

  4. Serializable isolation for shanpshot databases • Performance better than 2PL • Correctness better than SI

  5. Protocol - Basics • SI plus • Booleans InConflict and OutConflict for every transaction • SIRead locks • Does not block writes • Does not block on writes • Indicate rw-conflicts

  6. Protocol – Read by t1 • Request SIRead Lock • Write lock held by T2 => T1.InConflict = true & T2.OutConflict = true • For all versions (Ti) later than version read by T1 • T1.InConflict = True • Ti.OutConflict = True • Continue as in SI

  7. Protocol – Write by t1 • Request Write Lock (in SI) • SIREAD lock by T2 • T1.OutConflict = true • T2.InConflict = true • Create new version with timestamp T1 • Continue as in SI

  8. Protocol – Commit by t1 • T1.InConflict && T1.OutConflict => abort • Otherwise, same as SI

  9. Example Execution • R1(x)R1(y)R2(x)R2(y)W1(x)W2(y) • W1(x) sets T2.InConflict & T1.OutConflict • W2(y) sets T2.OutConflict & T1.InConflict • Commit request causes abort

  10. Example execution 2 • R1(x)R1(y)R2(x)R2(y)W1(x)c1W2(y) • SIREAD by T1 released at c1 problem • T2.OutConflict not set • Maintain locks past commit • Release when all concurrent transaction terminated

  11. All Schedules serializable • Assume Not: Cyclic SG and follow protocol • All ww/wr conflicts => commit cycle • One rw conflict • WLOG Tn -> T0 is rw • T0 commits before Tn-1 commits, before Tn starts => rw not possible • Two consecutive rw conflict • InConflict && OutConflict

  12. All Schedules Serializable • Two non-consecutive rw conflicts (to appear paper) • WLOG, Tn->T0 & Ti->Tj • T0 & Tnconcurrent, Ti & Tj concurrent • Path from T0 to Ti and Tj to Tn non-rw conflicts • T0 commits before Ti starts • Tj commits before Tn starts • Ti and Tj concurrent => T0 committed and Tn not started (not concurrent)

  13. Serializable schedule rejected • Conservative scheduler • R1(x) W2(x)R3(y)W1(y)c1 • Equivalent to T3 T1 T2 • W2(x) sets T1.InConflict • W1(y) sets T1.OutConflict • Abort T1 at c1

  14. PErformance

  15. Conclusion • Positive Theoretical Results • Excellent Performance under High Contention • Some problems under Low Contention Due to False Positives • Future Work - study increased detail to reduce false positives

More Related