2. Correctness of Transactions: Serialization

Transcription

1 2. Correctness of Transactions: Serialization 2.1 Formal Model 2.2 Conflict serializability 2.3 Other types of serializability 2.4 Recoverable transactions and more 2.5 Distributed TAs Es gibt nichts Praktischeres als eine gute Theorie. Material used from the Stanford DB group, Vossen/Weikum, Härder, in particular Phil Bernstein

2 Motivation and roadmap Given an interleaved execution of read and write steps of committed TA = {T 1,,T n } ( a history) Is the execution correct? Example: T 1 = r 1 [x] w 1 [x] T 2 = w 2 [x], T 3 = r 3 [y],w 3 [x] H = r 1 [x] w 2 [x], r 3 [y], w 1 [x],w 3 [x] Correct? Yes and no?! Needed: Correctness criteria There is more than one reasonable criterion HS-2010 HS / TA-Ser-1-2

3 Roadmap Serial execution is the norm: T i1, T i2,, T in Define equivalence relation(s) ~ among histories Those equivalent to an arbitrary serial execution history are correct Most important: conflict equivalence Any difference in case of distributed histories? (Yes) And then Concurrency control algorithms (next lecture) HS-2010 HS / TA-Ser-1-3

4 Formal definitions (1) Transaction T i 1. Partial order (T i ',<) of steps s i s i {r i [x], w i [x], x D, the set of Data items} {c i,a i } 2. a i T i c i T i 3. s i = c i s i = a i s i ' s i : s i ' < s i 4. r i [x], w i [x] T i r i [x] < w i [x] w i [x] < r i [x] For consistency reasons: each TA reads or writes an item only once r[x] w[x] r[y] r[z] w[y] c We use Ti as name for base set of actions instead of Ti' as well as for the partial order HS-2010 HS / TA-Ser-1-4

5 Formal definitions (2) History H of a finite set T = {T1,,Tn} of transactions is a partial order (H',<) of steps with 1. H =» Ti i.e. all steps of Ti, i=1 n occur 2. <» <i i.e. restriction of H to Ti is Ti 3. ri[x], wj[x] H, I j ri[x] < wj[x] wj[x] < ri[x] i.e all conflicting operations are ordered Role of aborts? Suppose aborted transactions can be eliminated as if they never occurred erase steps of aborted TA abort free (commit projected) history For now, history = abort free history HS-2010 HS / TA-Ser-1-5

6 Formal Definitions (3) Schedule S: Prefix of a history Sometimes: Schedule = "history", History = "Complete history" Serial history H: For every two transactions Ti, Tj: steps si of Ti, sj of Tj: si < sj or sj < si Serial Schedule S*: Serial history of the committed transactions of a schedule Allows to talk of serializable schedules, the ultimate goal concurrency control methods. HS-2010 HS / TA-Ser-1-6

7 Example T1 r1(x) r1(y) w1(x) T2 r2(x) c1 T3 r3(y) w2(x) c2 w3(z) w3(y) c3 Possible linear arrangement: r1(y) r3(y) r1(x) r2(x) w1(x)w2(x) w3(y) c1 w3(z) c3 c2 Total order! It is easy to extend a partial order to a total order HS-2010 HS / TA-Ser-1-7

8 Informal Correctness History of {T1,..., Tn} correct effect on DB is the same as the effect of some (arbitrary!) serial history. HS-2010 HS / TA-Ser-1-8

9 Conflicting operations Intuition: Two operations conflict if their execution order affects their return values or the DB state r and w on the same data item are in conflict wi and wj on the same data item conflict (note: must be steps of different TA) ri and rj on the same data item do not conflict No steps on different items are in conflict HS-2010 HS / TA-Ser-1-9

10 Conflicts Formal definition: Steps si[x] and sj[x'] of schedule S are in conflict i j and x = x' and s i, s j {r,w} and s i = r s j = w HS-2010 HS / TA-Ser-1-10

11 Conflict equivalence Histories H and H' are conflict equivalent (H ~ H') iff (1) H and H' with partial orders <H and <H' are defined for the same transaction set TA = {T1,,Tn} and every step of each Ti TA occurs in H and in H', (2) For conflicting operations si, sj, si Ti, sj Tj: si <H sj si <H' sj which simply means: all conflict pairs of any two TAs are scheduled in the same order. What about steps of different TAs which are not comparable with respect to <H? HS-2010 HS / TA-Ser-1-11

12 Examples of conflict equivalence The following histories are equivalent H 1 = r 1 [x] r 2 [x] w 1 [x] c 1 w 2 [y] c 2 H 2 = r 2 [x] r 1 [x] w 1 [x] c 1 w 2 [y] c 2 H 3 = r 2 [x] r 1 [x] w 2 [y] c 2 w 1 [x] c 1 H 4 = r 2 [x] w 2 [y] c 2 r 1 [x] w 1 [x] c 1 But none of them is equivalent to H 5 = r 1 [x] w 1 [x] r 2 [x] c 1 w 2 [y] c 2 because HS-2010 HS / TA-Ser-1-12

13 Conflict serializability A histories H is conflict serializable (H CS) iff there is a serial history H' and H ~ H' (H conflict equivalent to H') Most important equivalence criterion in practice Easy to implement concurrency control mechanisms which guarantee conflict serializability but restrictive Example from above: H = r1[x] r2[x] w2[x] w1[x] w3[x] Or: H = inc1[x] inc2[x] r2[y] w2[y]r1[y] w1[y] inc[x] is: increment(x), more operation semantics employed HS-2010 HS / TA-Ser-1-13

14 Example H= r 1 [x] r 2 [x] w 1 [x] r 3 [x] w 2 [y] w 3 [x] c 3 w 1 [y] c 1 c 2 is equivalent to a serial execution of T 2 T 1 T 3, H' = r 2 [x] w 2 [y] c 2 r 1 [x] w 1 [x] w 1 [y] c 1 r 3 [x] w 3 [x] c 3 Each conflict implies a constraint on any equivalent serial history: H = r 1 [x] r 2 [x] w 1 [x] r 3 [x] w 2 [y] w 3 [x] c 3 w 1 [y] c 1 c 2 T 2 T 3 T 2 T 1 T 1 T 3 T 2 T 1 HS-2010 HS / TA-Ser-1-14

15 Serializability theorem Conflict (Serialization) graph SG of a history H over TA ={T1,,Tn} is a directed graph (TA, E), E = {(Ti,Tj) there exists a conflict pair si Ti, sj Tj and si <H sj} Theorem: The conflictgraph SG of a history H over TA ={T1,,Tn} contains no cycle H is serializable Proof sketch: " " Cycle free graph can be topologically sorted: T i1,,t in " " suppose cycle of length n exists. Induction over n: n=2: T i1 T i2 and T i2 T i1 exist 2 conflict pairs s i1 <H s i2 and s' i2 <H s' i1 not serializable # induction step: HS-2010 HS / TA-Ser-1-15

16 Using the serializability theorem Characterize the set of histories that a concurrency control algorithm allows Prove that any such history must have an acyclic serialization graph. Therefore, the algorithm guarantees conflict serializable (CSR) executions. Important application of this method: the proof that 2- phase locking produces serializable executions. HS-2010 HS / TA-Ser-1-16

17 Relaxing conflict serializability View serializability: the idea Example: H = r2[y] w2[x] r1[x] r3[x] w1[y] w2[y] w3[y] c1 c2 c3 is not serializable But: H' = r2[y] w2[x] w2[y] c2 r1[x] w1[y] c1 r3[x] w3[y] c3 has the same effects View serializability: intuition If no TA reads an object x, another TA has produced (written), there does not exist a consistency threat for x HS-2010 HS / TA-Ser-1-17

18 Read-From relation H = r2[y] w2[x] r1[x] r3[x] w1[y] w2[y] w3[y] c1 c2 c3 T1 reads x from T2, T3 reads x from T2 In order to define the read-from relation, introduce transactions T 0 and T f ("final") T 0 writes all items before any step T f reads all items after all steps Let Ti, Tj, i j, be transactions of a schedule s. rj[x] reads from wi[x] if wi[x] is the last write step on x such that wi[x] < rj[x] HS-2010 HS / TA-Ser-1-18

19 View serializability The reads-from relation (RF) of a schedule H extended by T0 and Tf is defined by RF(H) = {(Ti,x,Tj): a read step rj(x) of Tj reads from a write step wi[x] of Tj} H = r2[y] w2[x] r1[x] r3[x] w1[y] w2[y] w3[y] c1 c2 c3 RF(H) = {(T2,x,T1), (T2,x,T3), (T0,y,T2), (T3,y,Tf), (T2,xTf)} HS-2010 HS / TA-Ser-1-19

20 View serializability A schedule H is view serializable (H VS) if RF(H) = RF(S) for some serial schedule S S = r2[y] w2[x] w2[y] c2 r1[x] w1[y] c1 r3[x] w3[y] c3 RF(S) = {(T0,y,T2), (T2,x,T1), (T2,x,T3), (T3,y,Tf), (T2,x,Tf)} = RF(H) HS-2010 HS / TA-Ser-1-20

21 Conflict and View serializability Conflict serializability stronger than view serializability CS VS?? Every conflict serializable schedule is view serializable Proof: H CS there is a serial schedule S with H ~ S, i.e. they have the same conflict relation. Show RF(H) = RF(S)... HS-2010 HS / TA-Ser-1-21

22 Problems Testing view equivalence of H and S: O( steps ), linear but: View serializability check if H: NP hard Even more serious (actually a consequence): No efficient concurrency control mechanism known for the more liberal view serializability criterion all cc algorithms conflict based, i.e. goal of the scheduler is to order conflicting steps in a consistent way HS-2010 HS / TA-Ser-1-22

23 Employing TA semantics Conflict serializability: easy to check correctness criterion purely syntactical (w, r), no knowledge about TAs, most general Can we do better? Yes, if we know something about TA applications Trivial: Ti, Tj only read data items... More involved: Ti is read only. Let it read the last consistent state of data items. multiple versions. Serialization?... HS-2010 HS / TA-Ser-1-23

24 Increment / Decrement Let inc i [x], dec j [y] be indivisible operations, {w,dec}, {w,inc}, {r,dec}, {r, inc} are potentially in conflict, {inc, inc}, {dec, dec}, {dec, inc} are not H = r1[x] inc2[y] inc1[y] w1[x] r2 [x] w2[x] is conflict serializable! T1 T2 Knowledge about the semantics of applications may allow for more liberal correctness criteria (and cc algorithms) and more parallelism HS-2010 HS / TA-Ser-1-24

25 Dealing with aborts Assumption up to now: When a transaction T aborts, the data manager wipes out all of T s effects undoing T s writes that were applied to the DB aborting transactions that read values written by T (called cascading aborts) Example w 1 [x] r 2 [x] w 2 [y] to abort T 1, we must undo w 1 [x] and abort T 2 (a cascading abort) Obviously serializable, but... HS-2010 HS / TA-Ser-1-25

26 Recoverability T k reads from T i and T i aborts T k must abort Example: w 1 [x] r 2 [x] a 1 T 2 must abort (cascading) Example - w 1 [x] r 2 [x] c 2 a 1?? Cannot compromise commit semantics of T2 Executions must be recoverable: A transaction commit operation of T must follow the commit of every transaction T' from which T read. w 1 [x] r 2 [x] c 1 c 2 recoverable w 1 [x] r 2 [x] c 2 a 1 not recoverable HS-2010 HS / TA-Ser-1-26

27 Recoverable TAs A schedule H is recoverable (H RC) : (Ti,x,Tj) RF(H) for some x, i 0, j f ci < cj (or simpler notation: (Ti,Tj) RF*(H) ci< cj ) Necessary: suitable synchronization mechanisms to guarantee recoverability. Two phase locking histories recoverable? What about cascading abort? w1[x] r2[x] w2[y] a1 can be tolerated, but expensive bookkeeping, forced aborts undesirable, may be several TAs to be aborted HS-2010 HS / TA-Ser-1-27

28 Cascading aborts Solution: w1[x] c1 r2[x] w2[y] A history avoids cascading aborts (H ACA) : (Ti,x,Tj) RF(H) for some x ci < rj[x] or: transactions read only committed data A system that avoids cascading aborts also guarantees recoverability: ACA RC H ACA, Ti reads from Tj wj[x] < cj < ri[x] for some x ci H ri[x] < ci cj < ci H RC Find an example showing that not every RC schedule is ACA HS-2010 HS / TA-Ser-1-28

29 Strictness Convenient to undo a write, w[x], by restoring its before image (= the value of x before w[x] executed) Example: w 1 [x,1] w 1 [y,3] c 1 w 2 [y,1] r 2 [x] a 2 wi[x,<value>] means: Ti writes <value> into x abort T 2: restore the before image of w 2 [y,1], = 3 Not always possible: w 1 [x,2] w 2 [x,3] a 1 a 2 a 1, a 2 can t be implemented by restoring before images notice that w 1 [x,2] w 2 [x,3] a 2 a 1 would be OK HS-2010 HS / TA-Ser-1-29

30 Strictness Informally: A history H is strict if only committed data are read or overwritten Obviously: strict ACA HS-2010 HS / TA-Ser-1-30

31 Strictness A history H is strict (H ST) : wj[x] < si[x], si[x] is read- or write-step of Ti cj < si[x] or aj < si[x] i.e. Ti reads or writes a data item x, if all TA, which wrote x committed or aborted. Examples w 1 [x] c 1 w 2 [x] a 2 w 1 [x] w 2 [x] a 1 a 2 w 1 [x] w 1 [y] c 1 w 2 [y] r 2 [x] a 2 w 1 [x] w 1 [y] w 2 [y] a 1 r 2 [x] a 2 ST ACA strict not strict strict not strict Strict implies avoids cascading aborts. HS-2010 HS / TA-Ser-1-31

32 Rigorousness Strictness means: item x written by Ti must not be read or written by a subsequent TA Tj until Ti committed What about writing x by Tj, if Ti read x, but did not commit yet? Example: H = w 1 [x] w 1 [y] r2 [u] w1[z] c 1 w 2 [x] r 2 [y] w 2 [y] w 3 [u] c3c2 H is strict, but T3 overwrites data before c2 read by T2 HS-2010 HS / TA-Ser-1-32

33 Rigorousness A history H is rigorous (H RG) : H is strict and for all TA Ti, Tj rj[x] < wi[x] cj < wi[x] or aj < wi[x] i.e. Ti writes a data item x not before all TA Tj which read x, have committed or aborted. Does this refinement make sense? No?: Influence on conflict serializability? Strictness? Yes: for serializability in heterogeneous distributed systems HS-2010 HS / TA-Ser-1-33

34 The big picture VSR ACA ST RG Serial RC CSR HS-2010 HS / TA-Ser-1-34

35 Distributed transactions: Local / global Global transactions: access data at multiple servers, steps at one or more location (relevant in both homogeneous and heterogeneous federations) Local transactions: run exclusively on a single server (relevant in heterogeneous federations) For now: global TAs HS-2010 HS / TA-Ser-1-35

36 Global history TA = { T1,..., Tm } executed in a federation of n sites Steps of Ti executed at different sites with local histories H1,, Hn H is a global history for TA with respect to H1,..., Hn if the local projections of H equal the local history at each site Πi(H) = Hi for 1 <= i <= n HS-2010 HS / TA-Ser-1-36

37 Example 2 sites, one holds x, the other y: Server 1: Server 2: r1(x) w2(x) c1 c2 w1(y) c1 r2(y) c2 t global history: s = r1(x) w1(y) w2(x) c1 r2(y) c2 Note: each site has to commit for each TA HS-2010 HS / TA-Ser-1-37

38 Global correctness Global conflict serializability A global history S is globally conflict serializable if there exists a serial history over the global (sub-) transactions that is conflict equivalent to S Local seralizability at all sites not sufficient Example: Server 1: r1(x) w2(x) c1 c2 Server 2: r2(y) c2 w1(y) c1 Local histories serializable, however global: r2(y) w1(y) r1(x) w2(x) c1 c2 HS-2010 HS / TA-Ser-1-38

39 Global conflict serializability Given: global history with local histories H1,..., Hn involving a set TA of transactions Ti and each Hi is conflict serializable. Theorem: S is globally conflict serializable iff there exists a total order < on TA that is consistent with each local serialization order of the transactions. Crucial point for isolation guarantee in distributed transactions: total ordering among the TA has to be established. Not a big deal in homogeneous distributed DB without autonomy but in heterogeneous, autonomous systems. HS-2010 HS / TA-Ser-1-39