1 / 21

Multiversion Concurrency Control Version 2.0

Multiversion Concurrency Control Version 2.0. Adrian Hudnott UK Ingres Users Association Conference 2010. Outline. Objectives Locking Oracle MVCC (& Ingres MVCC) Anomalies Allowable Behaviours OCC-SG Conclusions. Objectives. Mutual Exclusion Serialized Recoverable Concurrent

lamis
Download Presentation

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 UK Ingres Users Association Conference 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 • Serialization procedure • If a transaction i: • has rolled back, OR • has committed and there are no transactions time travelled before it • then put transaction i into the serialized list • Serialization list is emptied at each checkpoint 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