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 s au ie m ol ne F ge Distributed Locking – an – rg tel ve pi Ka Data is partitioned among nodes. 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. Introduction Strictness Example again: COCSR D1={a, b}; D 2={c, d}, Tickets global transactions T1=r(a) r(c); T 2=r(b) r(d), local transactions T3=w(a) w(b); T 4=w(c) w(d) The following local histories are not globally correct:
– s1=r 1(a) c 1 w3(a) w 3(b) c 3 r2(b) c 2
– s2=w 4(c) r 1(c) c 1 r2(d) c 2 w4(d) c 4 Objective must be:
execute T2 only if it cannot be part of a cycle.
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 28 Tickets (2) Convert indirect conflict into direct one that global TM can recognize. Additional data object in each database („ticket“). Introduction Strictness Comparable with logical timestamp. COCSR Each global transaction Tickets reads ticket, writes back incremented value. „Take-a-ticket“ operation .
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 29 Tickets – Example D1={a}, D 2={b, c}, global transactions T1=r(a) w(b); T 2=w(a) r(c) local transaction T =r(b) w(c) Introduction 3 Strictness possible local histories (without tickets): COCSR s1= r 1(a) c 1 w2(a) c 2 Tickets s2= r 3(b) w 1(b) c 1 r2(c) c 2 w3(c) c 3 use of tickets: s1= r 1(I 1) w 1(I 1+1) r 1(a) c 1 r2(I 1) w 2(I 1+1) w 2(a) c 2 s2= r 3(b) r 1(I 2) w 1(I 2+1) w 1(b) c 1 r2(I 2) w 2(I 2+1) r 2(c) c 2 w3(c) c 3 s2 not conflict-serializable any more. The following history would be OK: s2= r 1(I 2) w 1(I 2+1) w 1(b) c 1 r2(I 2) w 2(I 2+1) r 2(c) c 2 r3(b) w 3(c) c 3
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 30 Tickets – Comment If order of tickets is same on all nodes, different local serialization orders will incur a conflict on one node. Introduction Strictness Topic of next slides: How/when to enforce COCSR that ticket ordering is same on all nodes. Tickets
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 31 Optimistic vs. Conservative Ticket Approach Conservative ticket approach: global TM fixes order of transactions taking tickets. Introduction Also possible: Strictness COCSR optimistic approach to ensure Tickets the same serialization order on all components. TM simply issues ticket operations. TM must know their order of execution. Ticket order must be the same everywhere. Ticket-order graph: – global TM administers it. → – Edge T i Tj: a subtransaction of T i has read ticket before Tj. – Cycle ⇒ abort.
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 32 Discussion ‚lightweight‘ approach. Except for the fact that nodes must ‚tolerate‘ additional data objects, Introduction Strictness no further interference with node autonomy. COCSR Tickets
z
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 33 Potential Exam Questions Why are local transactions in distributed systems problematic from a concurrency-control point of view? Give an example of an indirect conflict. How can global serializability in federated DBMS be ensured? What are tickets? Why could they be preferred over alternative approaches?
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 34 Literature This material is taken from the chapter on federated DBMS in the Weikum/Vossen book.
Klemens Böhm Distributed Data Management: Transactions in Federated Databases – 35