1 / 26

Federated Transaction Management With Snapshot Isolation

Federated Transaction Management With Snapshot Isolation. Ralf Schenkel , Gerhard Weikum University of the Saarland, Saarbrücken Norbert Weißenberg Fraunhofer ISST, Dortmund Xuequn Wu Deutsche Telekom AG, Darmstadt. Motivation. Federated applications ask for

eron
Download Presentation

Federated Transaction Management With Snapshot Isolation

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. Federated Transaction Management With Snapshot Isolation Ralf Schenkel, Gerhard Weikum University of the Saarland, Saarbrücken Norbert Weißenberg Fraunhofer ISST, Dortmund Xuequn Wu Deutsche Telekom AG, Darmstadt

  2. Motivation Federated applications ask for • atomicity of distributed changes • correct execution (global concurrency control) • consistency preservation • durability of committed changes in a highly heterogeneous environment Transactions and Database Dynamics '99

  3. Motivation Federate applications ask for • atomicity of distributed changes • correct execution (global concurrency control) • consistency preservation • durability of committed changes in a highly heterogeneous environment Transactions and Database Dynamics '99

  4. Motivation Existing strategies for global CC • require locally serializable schedules • generate globally serializable schedules Real-life systems • may not support serializable schedules in all component databases (e.g. Oracle) • may use weaker correctness criteria for global schedules to increase performance (isolation levels) Transactions and Database Dynamics '99

  5. Overview of the Talk • Characterization of Snapshot Isolation • Global Snapshot Isolation • Global Serializability • Conclusion and Outlook Transactions and Database Dynamics '99

  6. Overview of the Talk • Execution Model • Definition of Snapshot Isolation (SI) • SI and Serializability • Graph Characterization of SI • Characterization of Snapshot Isolation • Global Snapshot Isolation • Global Serializability • Conclusion and Outlook Transactions and Database Dynamics '99

  7. Execution Model Multiversion Schedules of Transactions w0(x) w0(y) c0 r1(y)r2(y) w2(y) r2(x) w2(x) c2r1(x) c1 00 0 0 2 0 2 0 • Restrictions: • A transaction must • read an object before it writes this object • read and write an object at most once Transactions and Database Dynamics '99

  8. Definition of Snapshot Isolation A multiversion schedule is snapshot isolated (SI) if (SI-V) its version function maps each read operation to the last committed version of the object as of the start of the transaction (SI-W) the writesets of two concurrent transactions are disjoint. Properties: • Read-only transactions are never blocked. • Update hotspots in the database cause perfor- mance problems. Transactions and Database Dynamics '99

  9. SI and Serializability 50 50 50 50 (SI-W) aims to ensure serializability for snapshot isolated schedules: r1(x0)r2(x0)w1(x1) c1w2(x2) c2 is not serializable and not snapshot isolated. But this alone is not enough: r1(x0) r1(y0)r2(x0) r2(y0)w1(x1) c1w2(y2) c2 x+y0 -50 -50 is not serializable, but snapshot isolated. Transactions and Database Dynamics '99

  10. Graph Characterization of SI Definition: (SI-MVSG) The SI-MVSG for a schedule satisfying (SI-V) is the graph with transactions as nodes and the following edges: • ti tj attributed with x, if tj reads object x from ti; • tk ti attributed with x, if tj reads object x from ti, another transaction tk writes x and tk commits before ti; • tjtk attributed with x, if tj reads object x from ti, another transaction tk writes x and tk commits after ti; Theorem: A schedule satisfying (SI-V) is • serializable, if its SI-MVSG is cycle-free • snapshot isolated, if its SI-MVSG is x-cycle free. Transactions and Database Dynamics '99

  11. Example SI-MVSG x x x x r1(x0)r2(x0)w1(x1) c1w2(x2) c2 t1 t0 t2 x-cycle  not snapshot isolated (and not serializable) Transactions and Database Dynamics '99

  12. Example SI-MVSG x,y y x x,y r1(x0) r1(y0)r2(x0)r2(y0)w1(x1) c1w2(y2) c2 t1 t0 t2 cycle  not serializable, but snapshot isolated Transactions and Database Dynamics '99

  13. Overview of the Talk • Why this is a problem • Pessimistic Approach • Optimistic Approach • Characterization of Snapshot Isolation • Global Snapshot Isolation • Global Serializability • Conclusion and Outlook Transactions and Database Dynamics '99

  14. Global vs. Local SI Local SI in all components does not imply global SI: DB1:r1(a0) r2(x0)w2(x2) c2 r1(x0) c1 DB2:r2(y0) w2(y2) c2 r1(y2) w1(y1) c1 The global transactions t1 and t2 are concurrent, but their subtransactions are sequential in DB2, so • t1 reads from t2 in DB2, • both t1 and t2 write y in DB2.  additional protocols on top of the local schedulers Transactions and Database Dynamics '99

  15. Pessimistic Approach Synchronize Subtransaction Begins: Start all local subtransactions of a global transaction upon its first operation. DB1:b1 r1(a0) b2 r2(x0)w2(x2) c2 r1(x0) a1 DB2: b1 b2 r2(y0) w2(y2) c2 r1(y0) w1(y1) a1  global concurrency implies local concurrency  local Snapshot Isolation implies global SI Transactions and Database Dynamics '99

  16. Pessimistic Approach Advantages: • Easy to implement Problems: • Longer subtransactions • Subtransactions in all databases (unless the accessed databases are known in advance) Transactions and Database Dynamics '99

  17. Optimistic Approach a1 a1 Check for potential violations of global SI: Decide at commit time of transaction ti if the global execution is snapshot isolated, abort ti if • ti is globally concurrent with another transaction tk, and • tk is completely before ti in at least one database, and • ti reads from tk in that database. DB1: r1(a0) r2(x0)w2(x2) c2 r1(x0) DB2:r2(y0) w2(y2) c2 r1(y2) w1(y1) But: Reads-From relationship is hard to observe  check only the first two conditions  abort too many transactions Transactions and Database Dynamics '99

  18. Overview of the Talk • Why this is a problem • The Ticket Technique for SR schedulers • The Ticket Technique and Snapshot Isolation • Generalizing the Ticket Technique • Characterization of Snapshot Isolation • Global Snapshot Isolation • Global Serializability • Conclusion and Outlook Transactions and Database Dynamics '99

  19. Global Serializability Definition: A global schedule is serializable, if • all local subschedules are serializable, and • the serialization orders of all local subschedules are compatible. This is non-trivial: DB1: r1(x0) c1r2(x0)w2(x2) c2 DB2: r1(y0) w1(y1) c1r2(z0) c2 rL(y0) rL(z0) wL(zL) cL t2 tLt1  local transactions can break global serializability Transactions and Database Dynamics '99

  20. The Ticket Technique aL  tL must be aborted t2 tLt1 Principle: [Georgakopoulos , Rusinciewicz and Shet 1994] • Add increment of a ticket object to each subtransaction, forcing a conflict between global subtransactions • The relation of the ticket values reflects the serialization order of the subtransactions • Detect incompatible serialization orders using a graph • Additional optimizations depending on the local schedulers r1(T) w1(T+1) r2(T) w2(T+1) rL(y) rL(z) wL(z) r1(y) w1(y) c1r2(z) c2 4 5 5 6 But: All transactions are read-write Transactions and Database Dynamics '99

  21. Tickets and Snapshot Isolation • Concurrent execution is impossible: r1(y0) r2(z0) r1(T) w1(T+1)c1 r2(T) w2(T+1) a2  serial execution of all global transactions • Local serialization orders are unknown: rL(y) r1(y0) w1(y1) r1(T) w1(T+1)c1r2(z0) r2(T) w2(T+1) c2 rL(z) wL(z) cL  add ticket operation to local transactions Performance of the ticket technique is unacceptable with Snapshot Isolation Transactions and Database Dynamics '99

  22. Generalized Ticket Technique time T=6 T=7 T=9 T=7 T=8 Separate treatment for read-write and read-only TAs: • Read-write transactions: • ticket access as before, increase by 2 • Read-only transactions: • only read the ticket No performance degradation for read-only transactions Transactions and Database Dynamics '99

  23. Generalized Ticket Technique time T=6 T=8 time T=12 T=13 T=13 T=14 time T=7 T=7 T=46 T=48 T=47 T=49 Examples for federated transactions: Transactions and Database Dynamics '99

  24. Summary Snapshot Isolation in some important component DBs Guarantee Snapshot Guarantee Isolation for global Serializability for transactions global transactions Extension of the Synchronize Check if global existing ticket subtransaction begins Snapshot Isolation method in all DBMS holds at commit Transactions and Database Dynamics '99

  25. Ongoing Work • Consider Mixed Schedules (Combination of Snapshot Isolation and Serializability) • Enhance Optimistic Approach for Global Snapshot Isolation • Use Global Serialization Graph for Global Serializability • Evaluate Performance Transactions and Database Dynamics '99

  26. Discussion Ticket technique Local Scheduler Snapshot Isolation Disjoint Writesets MVSR S2PL 2PL Version Function SR ACA Reads-from Relationship Generalized Tickets Serialization Order SI-MVSG RG COSR 2PC Global Transaction Optimistic Approach OTS Transactions and Database Dynamics '99

More Related