1 / 21

Multiversion Concurrency Control Version 2.0

This document provides a comprehensive overview of Multi-Version Concurrency Control (MVCC) version 2.0, detailing its objectives, including mutual exclusion, serialization, and recoverability. It discusses the fundamental mechanisms of locking, highlighting the Oracle and Ingres MVCC implementations and associated anomalies. The paper introduces the Optimistic Concurrency Control Serialization Graph (OCC-SG) and its advantages in managing reads, writes, and transaction serialization effectively. Additionally, it contrasts classical locking methods with MVCC performance, noting the potential for improved efficiency and reduced starvation.

devin
Télécharger la présentation

Multiversion Concurrency Control Version 2.0

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. Multiversion Concurrency Control Version 2.0 Adrian Hudnott June 2010

  2. Outline • Objectives • Locking • Oracle MVCC (& Ingres MVCC) • Anomalies • Allowable Behaviours • OCC-SG • Conclusions

  3. Objectives • Mutual Exclusion • Serialized • Recoverable • Concurrent • Current • Minimum Wasted Work • Starvation Free

  4. Two Phase Locking

  5. Two Phase Locking

  6. MVCC

  7. 2 1 T(2) < T(1) Transaction 2 comes “before” transaction 1 Notation R(v,1); W(x,1); W(z,1); W(v,1); R(z,2); R(y,1); R(y,2); C(2); W(y,1); C(1) R(v,1) Transaction 1 reads v W(x,1) Transaction 1 writes to x C(2) Transaction 2 commits

  8. MVCC Version 1.0 R(x,1); W(x,1); R(x,2); W(x,2); C(1) Rollback 2 – first updater wins in Oracle & Ingres 10

  9. T(1) < T(2) • T(2) < T(1) • Contradiction! • Not prevented by first updater wins • Called “Write Skew” MVCC Version 1.0: Anomalies R(x,1); R(y,1); R(x,2); R(y,2); W(x,1); W(y,2); C(1); C(2)

  10. 2 1 • T(2) < T(1) • T(3) < T(2) • T(3) > T(1) • Transaction 3 reads y as committed by transaction 1 • Called “Read-Only Anomaly” 3 MVCC Version 1.0: Anomalies R(x,2); R(y,2); R(y,1); W(y,1); C(1); R(x,3); R(y,3); W(x,2); C(2)

  11. New Stuff 2 1 • T(3) < T(2) 3 MVCC Version 2.0: Allowable R(x,2); R(y,2); R(y,1); W(y,1); C(1); R(x,3); R(y,3); W(x,2); C(2) • T(2) < T(1) • T(3) < T(1) • Transaction 3 reads a version of y before transaction 1’s write • Transaction 3 has “time travelled” before transaction 1 • N.B. Cannot time travel before transactions in the same session

  12. MVCC Version 2.0: Allowable • Integrity constraint checking • Over limit rule: SELECT DISTINCT ‘Failed’ FROM CUSTOMER NATURAL JOIN ACCOUNT WHERE CREDIT_RATING < 100 AND BALANCE < -OVERDRAFT_LIMIT AND STATUS <> ‘Frozen’

  13. MVCC Version 2.0: Allowable

  14. MVCC Version 2.0: Allowable • Blind writes: R(x,1); W(x,1); W(x,2); C(1); C(2) • If T(1) < T(2) then write transaction 2’s value for x • If T(1) > T(2) then ignore transaction 2’s write request • Write-Write conflicts are a red herring under MVCC • Known as Thomas Write Rule

  15. OCC-SG: Basics • Record the serialization graph explicitly • For each element read or written, record: • Read list • Write list T(2) < T(3) graph[2][3]

  16. 1 2 3 1 2 3 OCC-SG: Writing • When a transaction i wants to write to x, inspect the read list. For each uncommitted transaction j: • If closure[ i ][ j ] is set then choose which transaction to rollback • Otherwise set graph[ j ][ i ] and update the closure • Write a new version of x Transitive closure

  17. OCC-SG: Reading • When a transaction i wants to read from x, inspect the write list. For each transaction j: • If i = j then skip to step 5 • If closure[ j ][ i ] is set then wait for transaction j to commit or rollback • Otherwise set graph[ i ][ j ] and update the closure • Scan the headers of the versions of x • Classify into before versions and after versions • Arrange the before versions in order. Ensure it is a total order. Add any new constraints to the graph. • Read the before versions in order, progressively applying the changes from the base revision

  18. OCC-SG: Serialization • Graph should not grow too large • If a transaction i: • has rolled back, OR • has committed and there are no active transactions time travelled before it • then transaction i can be serialized • Serialized transactions are moved to the serialized file • Eventually the beginning of the serialized file can be garbage collected (reference counting) Transaction ID 0 serialized 3rd

  19. Simulation Results

  20. Comparison

  21. Conclusions • Locking is safe but not fast enough • Oracle style MVCC performs better but is not safe • Oracle style MVCC rolls back some legitimate schedules • Protocols proposed in academia (e.g. OCC-DATI) are too optimistic (don’t rollback until a transaction is ready to commit) • Protocols proposed in academia lack industrial strength features such as statement level rollback • OCC-SG puts the serialization graph, previously a theoretical device, at the heart of the algorithm • OCC-SG combines the best features from Oracle / Ingres 10 and from academia • Still at the research stage, but a working simulation has been created in Java

More Related