Chapter 10: Transactions in Federated Databases Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 1 Topic of this Chapter Serializability in distributed systems (i.e., isolation). Several tansactions. Introduction One solution has already been proposed Strictness (see next slide). COCSR In this chapter, we look at one specific case Tickets (federated databases) where that solution is insufficient. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 2 – Folie aus vergangenem Kapitel – Data is partitioned among nodes. Distributed Locking Each node synchronizes operations that access data on its partition. No further communication (except for replicas): distributed execution of transactions and operations already adapted to distribution of data. Release of locks with strict 2PL as part of ACP. Biggest problem: global deadlocks. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 3 Global Transaction Management Works, but may be too optimistic. Global TM may synchronize global transactions. Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 4 Federated Databases Introduction Strictness COCSR Tickets Sales R&D Human Resources Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 5 Transaction Managmement in Federated DBMSs (1) Global Introduction Transactions Strictness COCSR Global Tickets TM Local TMs Local Transactions Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 6 Transaction Managmement in Federated DBMSs (2) Common assumption: all transactions under control of a global distributed transaction manager (TM). Introduction Now: local transactions Strictness COCSR unknown to the GTM in addition. Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 7 Transaction Managmement in Federated DBMSs (2) How to achieve global serializability? Introduction Is the following sufficient? Strictness Same concurrency-control protocol, and COCSR each server guarantees local serializability? Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 8 Example (1) D1={a}; D 2={b, c}, global transactions T1=r(a) w(b); T 2= r(c) w(a), Introduction local transactions T3=r(b) w(c). Strictness Why are T1 and T 2 global, and T3 is local? COCSR Tickets Global TM is ‚conservative‘; serial execution (T1; T 2). Possible local histories: server 1: s 1= r 1(a) w2(a) server 2: s 2= r3(b) w 1(b) r 2(c) w 3(c) What are the local serialization orders? Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 9 Example (2) Corresponding global history: s= r 1(a) r 3(b) w 1(b) r 2(c) w 2(a) w 3(c) ≈ ≈ Introduction s1, s 2 conflict-serializable: s 1 cT1T2; s 2 cT2T3T1 Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 10 Direct vs. Indirect Conflict Important distinction: direct conflict vs. indirect conflict . Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 11 Global Serializability – Overview Global serializability based on local guarantees. 1. Strictness, and commit is delayed , Introduction Strictness 2. commitment ordering. COCSR Tickets Tickets (do not require additional local guarantees; ticket ≡ additional local database object that global transactions must manipulate) Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 12 Strictness (1) strictness := write(x, val) is delayed until all transactions that have written x before Introduction have committed or aborted, Strictness COCSR + cascadelessness. Tickets Cascadelessness := Each transaction only reads values of committed transactions. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 13 Strictness (2) T1 = w 1[x] w 1[y] w 1[z] c 1 T2 = r 2[u] w 2[x] r 2[y] w 2[y] c 2 Introduction Strictness H9 = w 1[x] w 1[y] r 2[u] w 2[x] w 1[z] c 1 r2[y] w 2[y] c 2 COCSR Tickets H10 = w 1[x] w 1[y] r 2[u] w 1[z] c 1 w2[x] r 2[y] w 2[y] c 2 Which histories are strict? Which ones are cascadeless? Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 14 Strictness (3) Strictness alone does not suffice to ensure global serializability. Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 15 Strictness (4) Strictness alone does not suffice to ensure global serializability – example: D ={a,b}; D ={c,d}, Introduction 1 2 Strictness global transactions: T 1=w(a) w(d), T 2=w(c) w(b), COCSR local transactions: T = r(a) r(b), T = r(c) r(d), Tickets 3 4 local histories: s1= w 1(a) c 1 r3(a) r 3(b) c 3 w2(b) c 2 s2= w 2(c) c 2 r4(c) r 4(d) c 4 w1(d) c 1 s1 and s 2 are strict, but serialization orders differ. Observe that order of commits of global transactions differs between nodes. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 16 Strictness (5) Do not issue commit right away. Global transaction is commit-deferred := global TM sends commit to local sites Introduction Strictness only after the local sites have acknowledged COCSR execution of all operations. Tickets Global Transactions Global TM Local TMs Local Transactions Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 17 Strictness (6) Continuation of example: D1={a,b}; D 2={c,d} Introduction global transactions: Strictness T1= w(a) w(d), T 2= w(c) w(b) COCSR local transactions: T = r(a) r(b), T = r(c) r(d) Tickets 3 4 local histories: – s1= w 1(a) c 1 r3(a) r 3(b) c 3 w2(b) c 2 – s2= w 2(c) c 2 r4(c) r 4(d) c 4 w1(d) c 1 Not allowed. Deadlock situation. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 18 Strictness (7) Continuation of example: D1={a,b}; D 2={c,d} global transactions: T = w(a) w(d), T = w(c) w(b) Introduction 1 2 Strictness local transactions: T 3= r(a) r(b), T 4= r(c) r(d) COCSR local histories: Tickets – s1= w 1(a) c 1 r3(a) r 3(b) c 3 w2(b) c 2 – s2= w 2(c) c 2 r4(c) r 4(d) c 4 w1(d) c 1 c2 takes place strictly after c1 in s 1: – r3(a) after c 1 because of strictness. – w2(b) after r 3(b) according to serialization order. – c2 after w 2(b) because of commit-deferredness. Analogously, c1 takes place strictly after c2. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 19 Strictness (8) Theorem: let s be a global history for s1, ..., sn. ≤ ≤ si is strict for 1 i n, and all global transactions are commit-deferred. Introduction ⇒ s is globally serializable. Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 20 Strictness (9) Why is commit-deferredness, together with local serializability, not sufficient? Why do we need strictness as well? Introduction Strictness COCSR Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 21 Strictness (10) Running example: D1={a,b}; D 2={c,d} global transactions: T 1= w(a) w(d), T 2= w(c) w(b) Introduction Strictness local transactions: T 3= r(a) r(b), T 4= r(c) r(d) COCSR Global TM issues w1(a) and w 1(d). Tickets Then w2(c) and w 2(b). No guarantee that operations take place in that order. (At least when global TM does without handshaking.) Thus, local histories so far could be: – s1= w 1(a) r3(a) r 3(b) c 3 w2(b) – s2= w 2(c) r 4(c) r 4(d) c 4 w1(d) Global TM now issues c1, on both nodes. z Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 22 Commitment Ordering (1) Global serializability based on local guarantees. Approach 2: commitment ordering (COCSR). Introduction Commit order conflict serializability := Strictness Two transactions conflict. COCSR ⇒ Commit operations in conflict order. Tickets Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 23 Commitment Ordering (2) A DBMS that implements commitment ordering works as follows – example: applications issue w (x), w (x), c , Introduction 1 2 2 Strictness stricly after each other (handshaking). COCSR Now c1 is submitted to the DBMS – Tickets DBMS must reject it, must abort T1. Execution order w 1(x) w 2(x) c 2 c1 does not have commit operations in conflict order. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 24 Commitment Ordering (3) COCSR, and commits of global transactions are executed one after the other („handshaking“). ⇒ History is globally serializable. Introduction Strictness COCSR Tickets Global Transactions Global TM Local TMs Local Transactions Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 25 Commitment Ordering (4) Example – two histories: s1= r1(a) c 1 w3(a) w 3(b) c 3 r2(b) c 2 Introduction s2= w 4(c) r1(c) r2(d) r4(e) c1 c2 [w 4(d) c 4] Strictness COCSR Tickets Observe that s2 is not COCSR. Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 26 Commitment Ordering (5) Example – two histories: s1= r1(a) c 1 w3(a) w 3(b) c 3 r2(b) c 2 Introduction s2= w 4(c) r1(c) r2(d) r4(e) c1 c2 [w 4(d) c 4] Strictness COCSR Tickets Observe that s2 is not COCSR. Why is COCSR alone not sufficient? Suppose c1 and c 2 are issued in parallel; c1 is delayed. This may result in commit order c 2 c4 c1. I.e., COCSR on both sites, but no local serializability. z Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 27 Tickets (1) In what follows: nodes do not offer additional properties such as strictness or COCSR, only CSR locally.