Transactional Information Systems:

Transcription

1 Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery Gerhard Weikum and Gottfried Vossen Teamwork is essential. It allows you to blame someone else. (Anonymous) 4/18/2005 Transactional Information Systems 3-1

2 Part II: Concurrency Control 3 Concurrency Control: Notions of Correctness for the Page Model 4 Concurrency Control Algorithms 5 Multiversion Concurrency Control 6 Concurrency Control on Objects: Notions of Correctness 7 Concurrency Control Algorithms on Objects 8 Concurrency Control on Relational Databases 9 Concurrency Control on Search Structures 10 Implementation and Pragmatic Issues 4/18/2005 Transactional Information Systems 3-2

3 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned Nothing is as practical as a good theory. (Albert Einstein) 4/18/2005 Transactional Information Systems 3-3

4 Lost Update Problem P1 Time P2 /* x = 100 */ r (x) 1 2 r (x) x := x x := x+200 w (x) 5 /* x = 200 */ 6 w (x) /* x = 300 */ update lost Observation: problem is the interleaving r 1 (x) r 2 (x) w 1 (x) w 2 (x) 4/18/2005 Transactional Information Systems 3-4

5 Inconsistent Read Problem P1 Time P2 1 r (x) 2 x := x 10 3 w (x) sum := 0 4 r (x) 5 r (y) 6 sum := sum +x 7 sum := sum + y 8 9 r (y) 10 y := y w (y) sees wrong sum Observations: problem is the interleaving r 2 (x) w 2 (x) r 1 (x) r 1 (y) r 2 (y) w 2 (y) no problem with sequential execution 4/18/2005 Transactional Information Systems 3-5

6 Dirty Read Problem P1 Time P2 r (x) 1 x := x w (x) 3 4 r (x) 5 x := x failure & rollback 6 7 w (x) cannot rely on validity of previously read data Observation: transaction rollbacks could affect concurrent transactions 4/18/2005 Transactional Information Systems 3-6

7 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-7

8 Schedules and Histories Definition 3.1 (Schedules and histories): Let T={t 1,..., t n } be a set of transactions, where each t i T has the form t i =(op i, < i ) with op i denoting the operations of t i and < i their ordering. (i) A history for T is a pair s=(op(s),< s ) s.t. (a) op(s) i=1..n op i i=1..n {a i, c i } (b) for all i, 1 i n: c i op(s) a i op(s) (c) i=1..n < i < s (d) for all i, 1 i n, and all p op i : p < s c i or p < s a i (e) for all p, q op(s) s.t. at least one of them is a write and both access the same data item: p < s q or q < s p (ii) A schedule is a prefix of a history. Definition 3.2 (Serial history): A history s is serial if for any two transactions t i and t j in s, where i j, all operations from t i are ordered in s before all operations from t j or vice versa. 4/18/2005 Transactional Information Systems 3-8

9 Example Schedules and Notation Example 3.4: r 1 (x) w 1 (x) c 1 r 1 (z) r 2 (x) w 2 (y) c 2 r 3 (z) w 3 (y) c 3 w 3 (z) trans(s):= {t i s contains step of t i } commit(s):= {t i trans(s) c i s} abort(s):= {t i trans(s) a i s} active(s):= trans(s) (commit(s) abort(s)) Example 3.6: r 1 (x) r 2 (z) r 3 (x) w 2 (x) w 1 (x) r 3 (y) r 1 (y) w 1 (y) w 2 (z) w 3 (z) c 1 a 3 4/18/2005 Transactional Information Systems 3-9

10 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-10

11 Correctness of Schedules 1. Define equivalence relation on set S of all schedules. This leads to a decomposition of S into equivalence classes. 2. Good schedules are those in the equivalence classes of serial schedules. An appropriately chosen equivalence relation fulfills the following prerequisites: Equivalence is efficiently decidable. Good equivalence classes are sufficiently large. For the moment, disregard aborts: assume that all transactions are committed. 4/18/2005 Transactional Information Systems 3-11

12 Activity Define a notion of equivalence for schedules via a notion of semantics (Herbrand semantics). Define serializability via equivalence to serial histories. 4/18/2005 Transactional Information Systems 3-12

13 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-13

14 Herbrand Semantics of Schedules Definition 3.3 (Herbrand Semantics of Steps): For schedule s the Herbrand semantics H s of steps r i (x), w i (x) op(s) is: (i) H s [r i (x)] := H s [w j (x)] where w j (x) is the last write on x in s before r i (x). (ii) H s [w i (x)] := f ix (H s [r i (y 1 )],..., H s [r i (y m )]) where the r i (y j ), 1 j m, are all read operations of t i that occcur in s before w i (x) and f ix is an uninterpreted m-ary function symbol. Definition 3.4 (Herbrand Universe): For data items D={x, y, z,...} and transactions t i, 1 i n, the Herbrand universe HU is the smallest set of symbols s.t. (i) f 0x ( ) HU for each x D where f 0x is a constant, and (ii) if w i (x) op i for some t i, there are m read operations r i (y 1 ),..., r i (y m ) that precede w i (x) in t i, and v 1,..., v m HU, then f ix (v 1,..., v m ) HU. Definition 3.5 (Schedule Semantics): The Herbrand semantics of a schedule s is the mapping H[s]: D HU defined by H[s](x) := H s [w i (x)], where w i (x) is the last operation from s writing x, for each x D. 4/18/2005 Transactional Information Systems 3-14

15 Herbrand Semantics: Example s = w 0 (x) w 0 (y) c 0 r 1 (x) r 2 (y) w 2 (x) w 1 (y) c 2 c 1 H s [w 0 (x)] = f 0x ( ) H s [w 0 (y)] = f 0y ( ) H s [r 1 (x)] = H s [w 0 (x)] = f 0x ( ) H s [r 2 (y)] = H s [w 0 (y)] = f 0y ( ) H s [w 2 (x)] = f 2x (H s [r 2 (y)]) = f 2x (f 0y ( )) H s [w 1 (y)] = f 1y (H s [r 1 (x)]) = f 1y (f 0x ( )) H[s](x) = H s [w 2 (x)] = f 2x (f 0y ( )) H[s](y) = H s [w 1 (y)] = f 1y (f 0x ( )) 4/18/2005 Transactional Information Systems 3-15

16 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-16

17 Final-State Equivalence Definition 3.6 (Final State Equivalence): Schedules s and s are called final state equivalent, denoted s f s, if op(s)=op(s ) and H[s]=H[s ]. Example a: s= r 1 (x) r 2 (y) w 1 (y) r 3 (z) w 3 (z) r 2 (x) w 2 (z) w 1 (x) s = r 3 (z) w 3 (z) r 2 (y) r 2 (x) w 2 (z) r 1 (x) w 1 (y) w 1 (x) H[s](x) = H s [w 1 (x)] = f 1x (f 0x ( )) = H s [w 1 (x)] = H[s ](x) H[s](y) = H s [w 1 (y)] = f 1y (f 0x ( )) = H s [w 1 (y)] = H[s ](y) H[s](z) = H s [w 2 (z)] = f 2z (f 0x ( ), f 0y ( )) = H s [w 2 (z)] = H[s ](z) Example b: s= r 1 (x) r 2 (y) w 1 (y) w 2 (y) s = r 1 (x) w 1 (y) r 2 (y) w 2 (y) H[s](y) = H s [w 2 (y)] = f 2y (f 0y ( )) H[s ](y) = H s [w 2 (y)] = f 2y (H s (r 2 (y))) = f 2y (H s (w 1 (y))) f 2y (f 1y (H s (r 1 (x)))) = f 2y (f 1y (f 0x ( ))) s f s (s f s ) 4/18/2005 Transactional Information Systems 3-17

18 Reads-from Relation Definition 3.7 (Reads-from Relation; Useful, Alive, and Dead Steps): Given a schedule s, extended with an initial and a final transaction, t 0 and t. (i) r j (x) reads x in s from w i (x) if w i (x) is the last write on x s.t. w i (x) < s r j (x). (ii) The reads-from relation of s is RF(s) := {(t i, x, t j ) an r j (x) reads x from a w i (x)}. (iii) Step p is directly useful for step q, denoted p q, if q reads from p, or p is a read step and q is a subsequent write step of the same transaction. *, the useful relation, denotes the reflexive and transitive closure of. (iv) Step p is alive in s if it is useful for some step from t, and dead otherwise. (v) The live-reads-from relation of s is LRF(s) := {(t i, x, t j ) an alive r j (x) reads x from w i (x)} Example 3.7: s= r 1 (x) r 2 (y) w 1 (y) w 2 (y) s = r 1 (x) w 1 (y) r 2 (y) w 2 (y) RF(s) = {(t 0,x,t 1 ), (t 0,y,t 2 ), (t 0,x,t ), (t 2,y,t )} RF(s ) = {(t 0,x,t 1 ), (t 1,y,t 2 ), (t 0,x,t ), (t 2,y,t )} LRF(s) = {(t 0,y,t 2 ), (t 0,x,t ), (t 2,y,t )} LRF(s ) = {(t 0,x,t 1 ), (t 1,y,t 2 ), (t 0,x,t ), (t 2,y,t )} 4/18/2005 Transactional Information Systems 3-18

19 Final-State Serializability Theorem 3.1: For schedules s and s the following statements hold. (i) s f s iff op(s)=op(s ) and LRF(s)=LRF(s ). (ii) For s let the step graph D(s)=(V,E) be a directed graph with vertices V:=op(s) and edges E:={(p,q) p q}, and the reduced step graph D 1 (s) be derived from D(s) by removing all vertices that correspond to dead steps. Then LRF(s)=LRF(s ) iff D 1 (s)=d 1 (s ). Corollary 3.1: Final-state equivalence of two schedules s and s can be decided in time that is polynomial in the length of the two schedules. Definition 3.8 (Final State Serializability): A schedule s is final state serializable if there is a serial schedule s s.t. s f s. FSR denotes the class of all final-state serializable histories. 4/18/2005 Transactional Information Systems 3-19

20 FSR: Example 3.9 s= r 1 (x) r 2 (y) w 1 (y) w 2 (y) D(s): s = r 1 (x) w 1 (y) r 2 (y) w 2 (y) D(s ): w 0 (x) w 0 (y) w 0 (x) w 0 (y) r 2 (y) r 1 (x) w 1 (y) r 1 (x) w 1 (y) r 2 (y) w 2 (y) w 2 (y) r (x) r (y) r (x) r (y) dead steps 4/18/2005 Transactional Information Systems 3-20

21 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-21

22 Canonical Anomalies Reconsidered Lost update anomaly: L = r 1 (x) r 2 (x) w 1 (x) w 2 (x) c 1 c 2 history is not FSR LRF(L) = {(t 0,x,t 2 ), (t 2,x,t )} LRF(t 1 t 2 ) = {(t 0,x,t 1 ), (t 1,x,t 2 ), (t 2,x,t )} LRF(t 2 t 1 ) = {(t 0,x,t 2 ), (t 2,x,t 1 ), (t 1,x,t )} Inconsistent read anomaly: I = r 2 (x) w 2 (x) r 1 (x) r 1 (y) r 2 (y) w 2 (y) c 1 c 2 history is FSR! LRF(I) = {(t 0,x,t 2 ), (t 0,y,t 2 ), (t 2,x,t ), (t 2,y,t )} LRF(t 1 t 2 ) = {(t 0,x,t 2 ), (t 0,y,t 2 ), (t 2,x,t ), (t 2,y,t )} LRF(t 2 t 1 ) = {(t 0,x,t 2 ), (t 0,y,t 2 ), (t 2,x,t ), (t 2,y,t )} Observation: (Herbrand) semantics of all read steps matters! 4/18/2005 Transactional Information Systems 3-22

23 View Serializability Definition 3.9 (View Equivalence): Schedules s and s are view equivalent, denoted s v s, if the following hold: (i) op(s)=op(s ) (ii) H[s] = H[s ] (iii) H s [p] = H s [p] for all (read or write) steps Theorem 3.2: For schedules s and s the following statements hold. (i) s v s iff op(s)=op(s ) and RF(s)=RF(s ) (ii) s v s iff D(s)=D(s ) Corollary 3.2: View equivalence of two schedules s and s can be decided in time that is polynomial in the length of the two schedules. Definition 3.10 (View Serializability): A schedule s is view serializable if there exists a serial schedule s s.t. s v s. VSR denotes the class of all view-serializable histories. 4/18/2005 Transactional Information Systems 3-23

24 Inconsistent Read Reconsidered Inconsistent read anomaly: I = r 2 (x) w 2 (x) r 1 (x) r 1 (y) r 2 (y) w 2 (y) c 1 c 2 history is not VSR! RF(I) = {(t 0,x,t 2 ), (t 2,x,t 1 ), (t 0,y,t 1 ), (t 0,y,t 2 ), (t 2,x,t ), (t 2,y,t )} RF(t 1 t 2 ) = {(t 0,x,t 1 ), (t 0,y,t 1 ), (t 0,x,t 2 ), (t 0,y,t 2 ), (t 2,x,t ), (t 2,y,t )} RF(t 2 t 1 ) = {(t 0,x,t 2 ), (t 0,y,t 2 ), (t 2,x,t 1 ), (t 2,y,t 1 ), (t 2,x,t ), (t 2,y,t )} Observation: VSR properly captures our intuition 4/18/2005 Transactional Information Systems 3-24

25 Relationship Between VSR and FSR Theorem 3.3: VSR FSR. Theorem 3.4: Let s be a history without dead steps. Then s VSR iff s FSR. 4/18/2005 Transactional Information Systems 3-25

26 On the Complexity of Testing VSR Theorem 3.5: The problem of deciding for a given schedule s whether s VSR holds is NP-complete. 4/18/2005 Transactional Information Systems 3-26

27 Properties of VSR Definition 3.11 (Monotone Classes of Histories) Let s be a schedule and T trans(s). Π T (s) denotes the projection of s onto T. A class E of histories is called monotone if the following holds: if s is in E, then Π T (s) is in E for each T trans(s). VSR is not monotone. Example: s = w 1 (x) w 2 (x) w 2 (y) c 2 w 1 (y) c 1 w 3 (x) w 3 (y) c 3 Π {t1, t2} (s) = w 1 (x) w 2 (x) w 2 (y) c 2 w 1 (y) c 1 VSR VSR 4/18/2005 Transactional Information Systems 3-27

28 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-28

29 Conflict Serializability Definition 3.12 (Conflicts and Conflict Relations): Let s be a schedule, t, t trans(s), t t. (i) Two data operations p t and q t are in conflict in s if they access the same data item and at least one of them is a write. (ii) {(p, q)} p, q are in conflict and p < s q} is the conflict relation of s. Definition 3.13 (Conflict Equivalence): Schedules s and s are conflict equivalent, denoted s c s, if op(s) = op(s ) and conf(s) = conf(s ). Definition 3.14 (Conflict Serializability): Schedule s is conflict serializable if there is a serial schedule s s.t. s c s. CSR denotes the class of all conflict serializable schedules. Example a: r 1 (x) r 2 (x) r 1 (z) w 1 (x) w 2 (y) r 3 (z) w 3 (y) c 1 c 2 w 3 (z) c 3 Example b: r 2 (x) w 2 (x) r 1 (x) r 1 (y) r 2 (y) w 2 (y) c 1 c 2 CSR CSR 4/18/2005 Transactional Information Systems 3-29

30 Properties of CSR Theorem 3.8: CSR VSR Example: s = w 1 (x) w 2 (x) w 2 (y) c 2 w 1 (y) c 1 w 3 (x) w 3 (y) c 3 s VSR, but s CSR. Theorem 3.9: (i) CSR is monotone. (ii) s CSR Π T (s) VSR for all T trans(s) (i.e., CSR is the largest monotone subset of VSR). 4/18/2005 Transactional Information Systems 3-30

31 Activity What is a directed graph? Think of ways to associate a graph with a schedule! 4/18/2005 Transactional Information Systems 3-31

32 Conflict Graph Definition 3.15 (Conflict Graph): Let s be a schedule. The conflict graph G(s) = (V, E) is a directed graph with vertices V := commit(s) and edges E := {(t, t ) t t and there are steps p t, q t with (p, q) conf(s)}. Theorem 3.10: Let s be a schedule. Then s CSR iff G(s) is acyclic. Corollary 3.4: Testing if a schedule is in CSR can be done in time polynomial to the schedule s number of transactions. Example 3.12: s = r 1 (y) r 3 (w) r 2 (y) w 1 (y) w 1 (x) w 2 (x) w 2 (z) w 3 (x) c 1 c 3 c 2 G(s): t1 t2 t3 4/18/2005 Transactional Information Systems 3-32

33 Activity What is a characterization (in a mathematical sense)? How do you prove a necessary and sufficient condition? What needs to be shown for the serializability theorem? 4/18/2005 Transactional Information Systems 3-33

34 Proof of the Conflict-Graph Theorem (i) Let s be a schedule in CSR. So there is a serial schedule s with conf(s) = conf(s ). Now assume that G(s) has a cycle t 1 t 2... t k t 1. This implies that there are pairs (p 1, q 2 ), (p 2, q 3 ),..., (p k, q 1 ) with p i t i, q i t i, p i < s q (i+1), and p i in conflict with q (i+1). Because s c s, it also implies that p i < s q (i+1). Because s is serial, we obtain t i < s t (i+1) for i=1,..., k-1, and t k < s t 1. By transitivity we infer t 1 < s t 2 and t 2 < s t 1, which is impossible. This contradiction shows that the initial assumption is wrong. So G(s) is acyclic. (ii) Let G(s) be acyclic. So it must have at least one source node. The following topological sort produces a total order < of transactions: a) start with a source node (i.e., a node without incoming edges), b) remove this node and all its outgoing edges, c) iterate a) and b) until all nodes have been added to the sorted list. The total transaction ordering order < preserves the edges in G(s); therefore it yields a serial schedule s for which s c s. 4/18/2005 Transactional Information Systems 3-34

35 Commutativity and Ordering Rules Commutativity rules: C1: r i (x) r j (y) ~ r j (y) r i (x) if i j C2: r i (x) w j (y) ~ w j (y) r i (x) if i j and x y C3: w i (x) w j (y) ~ w j (y) w i (x) if i j and x y Ordering rule: C4: o i (x), p j (y) unordered ~> o i (x) p j (y) if x y or both o and p are reads Example for transformations of schedules: s = w 1 (x) r 2 (x) w 1 (y) w 1 (z) r 3 (z) w 2 (y) w 3 (y) w 3 (z) ~>[C2] w 1 (x) w 1 (y) r 2 (x) w 1 (z) w 2 (y) r 3 (z) w 3 (y) w 3 (z) ~>[C2] w 1 (x) w 1 (y) w 1 (z) r 2 (x) w 2 (y) r 3 (z) w 3 (y) w 3 (z) = t 1 t 2 t 3 4/18/2005 Transactional Information Systems 3-35

36 Commutativity-based Reducibility Definition 3.16 (Commutativity Based Equivalence): Schedules s and s s.t. op(s)=op(s ) are commutativity based equivalent, denoted s ~* s, if s can be transformed into s by applying rules C1, C2, C3, C4 finitely many times. Theorem 3.11: Let s and s be schedules s.t. op(s)=op(s ). Then s c s iff s ~* s. Definition 3.17 (Commutativity Based Reducibility): Schedule s is commutativity-based reducible if there is a serial schedule s s.t. s ~* s. Corollary 3.5: Schedule s is commutativity-based reducible iff s CSR. 4/18/2005 Transactional Information Systems 3-36

37 Order Preserving Conflict Serializability Definition 3.18 (Order Preservation): Schedule s is order preserving conflict serializable if it is conflict equivalent to a serial schedule s and for all t, t trans(s): if t completely precedes t in s, then the same holds in s. OCSR denotes the class of all schedules with this property. Theorem 3.12: OCSR CSR. Example 3.13: s = w 1 (x) r 2 (x) c 2 w 3 (y) c 3 w 1 (y) c 1 CSR OCSR 4/18/2005 Transactional Information Systems 3-37

38 Commit-order Preserving Conflict Serializability Definition 3.19 (Commit Order Preservation): Schedule s is commit order preserving conflict serializable if for all t i, t j trans(s): if there are p t i, q t j with (p,q) conf(s) then c i < s c j. COCSR denotes the class of all schedules with this property. Theorem 3.13: COCSR CSR. Theorem 3.14: Schedule s is in COCSR iff there is a serial schedule s s.t. s c s and for all t i, t j trans(s): t i < s t j c i < s c j. Theorem 3.15: COCSR OCSR. Example: s = w 3 (y) c 3 w 1 (x) r 2 (x) c 2 w 1 (y) c 1 OCSR COCSR 4/18/2005 Transactional Information Systems 3-38

39 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-39

40 Commit Serializability Definition 3.20 (Closure Properties of Schedule Classes): Let E be a class of schedules. For schedule s let CP(s) denote the projection Π commit(s) (s). E is prefix-closed if the following holds: s E p E for each prefix of s. E is commit-closed if the following holds: s E CP(s) E. Theorem 3.16: CSR is prefix-commit-closed, i.e., prefix-closed and commit-closed. Definition 3.21 (Commit Serializability): Schedule s is commit-θ-serializable if CP(p) is Θ-serializable for each prefix p of s, where Θ can be FSR, VSR, or CSR. The resulting classes of commit-θ-serializable schedules are denoted CMFSR, CMVSR, and CMCSR. Theorem 3.17: (i) CMFSR, CMVSR, CMCSR are prefix-commit-closed. (ii) CMCSR CMVSR CMFSR 4/18/2005 Transactional Information Systems 3-40

41 Landscape of History Classes 4/18/2005 Transactional Information Systems 3-41

42 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-42

43 Interleaving Specifications: Motivation Example: all transactions known in advance transfer transactions on checking accounts a and b and savings account c: t 1 = r 1 (a) w 1 (a) r 1 (c) w 1 (c) t 2 = r 2 (b) w 2 (b) r 2 (c) w 2 (c) balance transaction: t 3 = r 3 (a) r 3 (b) r 3 (c) audit transaction: t 4 = r 4 (a) r 4 (b) r 4 (c) w 4 (z) Possible schedules: r 1 (a) w 1 (a) r 2 (b) w 2 (b) r 2 (c) w 2 (c) r 1 (c) w 1 (c) r 1 (a) w 1 (a) r 3 (a) r 3 (b) r 3 (c) r 1 (c) w 1 (c) r 1 (a) w 1 (a) r 2 (b) w 2 (b) r 1 (c) r 2 (c) w 2 (c) w 1 (c) r 1 (a) w 1 (a) r 4 (a) r 4 (b) r 4 (c) w 4 (z) r 1 (c) w 1 (c) CSR CSR CSR CSR application-tolerable interleavings non-admissable interleavings Observations: application may tolerate non-csr schedules a priori knowledge of all transactions impractical 4/18/2005 Transactional Information Systems 3-43

44 Indivisible Units Definition 3.22 (Indivisible Units): Let T={t 1,..., t n } be a set of transactions. For t i, t j T, t i t j, an indivisible unit of t i relative to t j is a sequence of consecutive steps of t i s.t. no operations of t j are allowed to interleave with this sequence. IU(t i, t j ) denotes the ordered sequence of indivisible units of t i relative to t j. IU k (t i, t j ) denotes the k th element of IU(t i, t j ). Example 3.14: t 1 = r 1 (x) w 1 (x) w 1 (z) r 1 (y) t 2 = r 2 (y) w 2 (y) r 2 (x) t 3 = w 3 (x) w 3 (y) w 3 (z) IU(t 1, t 2 ) = < [r 1 (x) w 1 (x)], [w 1 (z) r 1 (y)] > IU(t 1, t 3 ) = < [r 1 (x) w 1 (x)], [w 1 (z)], [r 1 (y)] > IU(t 2, t 1 ) = < [r 2 (y)], [w 2 (y) r 2 (x)] > IU(t 2, t 3 ) = < [r 2 (y) w 2 (y)], [r 2 (x)] > IU(t 3, t 1 ) = < [w 3 (x) w 3 (y)], [w 3 (z)] > IU(t 3, t 2 ) = < [w 3 (x) w 3 (y)], [w 3 (z)] > Example 3.15: s 1 = r 2 (y) r 1 (x) w 1 (x) w 2 (y) r 2 (x) w 1 (z) w 3 (x) w 3 (y) r 1 (y) w 3 (z) respects all IUs s 2 = r 1 (x) r 2 (y) w 2 (y) w 1 (x) r 2 (x) w 1 (z) r 1 (y) violates IU 1 (t 1, t 2 ) and IU 2 (t 2, t 1 ) but is conflict equivalent to an allowed schedule 4/18/2005 Transactional Information Systems 3-44

45 Relatively Serializable Schedules Definition 3.23 (Dependence of Steps): Step q directly depends on step p in schedule s, denoted p~>q, if p < s q and either p, q belong to the same transaction t and p < t q or p and q are in conflict. ~>* denotes the reflexive and transitive closure of ~>. Definition 3.24 (Relatively Serial Schedule): s is relatively serial if for all transactions t i, t j : if q t j is interleaved with some IU k (t i, t j ), then there is no operation p IU k (t i, t j ) s.t. p~>* q or q~>* p Example 3.16: s 3 = r 1 (x) r 2 (y) w 1 (x) w 2 (y) w 3 (x) w 1 (z) w 3 (y) r 2 (x) r 1 (y) w 3 (z) Definition 3.25 (Relatively Serializable Schedule): s is relatively serializable if it is conflict equivalent to a relatively serial schedule. Example 3.17: s 4 = r 1 (x) r 2 (y) w 2 (y) w 1 (x) w 3 (x) r 2 (x) w 1 (z) w 3 (y) r 1 (y) w 3 (z) 4/18/2005 Transactional Information Systems 3-45

46 Relative Serialization Graph Definition 3.26 (Push Forward and Pull Backward): Let IU k (t i, t j ) be an IU of t i relative to t j. For an operation p i IU k (t i, t j ) let (i) F(p i, t j ) be the last operation in IU k (t i, t j ) and (ii) B(p i, t j ) be the first operation in IU k (t i, t j ). Definition 3.27 (Relative Serialization Graph): The relative serialization graph RSG(s) = (V,E) of schedule s is a graph with vertices V := op(s) and edge set E V V containing four types of edges: (i) for consecutive operations p, q of the same transaction (p, q) E (I-edge) (ii) if p ~>* q for p t i, q t j, t i t j, then (p, q) E (D-edge) (iii) if (p, q) is a D-edge with p t i, q t j, then (F(p, t j ), q) E (F-edge) (iv) if (p,q ) is a D-edge with p t i, q t j, then (p, B(q, t i )) E (B-edge) Theorem 3.18: A schedule s is relatively serializable iff RSG(s) is acyclic. 4/18/2005 Transactional Information Systems 3-46

47 RSG Example Example 3.19: t 1 = w 1 (x) r 1 (z) t 2 = r 2 (x) w 2 (y) t 3 = r 3 (z) r 3 (y) IU(t 1, t 2 ) = < [w 1 (x) r 1 (z)] > IU(t 1, t 3 ) = < [w 1 (x)], [r 1 (z)] > IU(t 2, t 1 ) = < [r 2 (x)], [w 2 (y)] > IU(t 2, t 3 ) = < [r 2 (x)], [w 2 (y)] > IU(t 3, t 1 ) = < [r 3 (z)], [r 3 (y)] > IU(t 3, t 2 ) = < [r 3 (z) r 3 (y)] > s 5 = w 1 (x) r 2 (x) r 3 (z) w 2 (y) r 3 (y) r 1 (z) RSG(s 5 ): D,B w 1 (x) D,B I F r 1 (z) F r 2 (x) D,F,B I w 2 (y) B D,F B D,F r 3 (z) I r 3 (y) 4/18/2005 Transactional Information Systems 3-47

48 Chapter 3: Concurrency Control Notions of Correctness for the Page Model 3.2 Canonical Synchronization Problems 3.3 Syntax of Histories and Schedules 3.4 Correctness of Histories and Schedules 3.5 Herbrand Semantics of Schedules 3.6 Final-State Serializability 3.7 View Serializability 3.8 Conflict Serializability 3.9 Commit Serializability 3.10 An Alternative Criterion: Interleaving Specifications 3.11 Lessons Learned 4/18/2005 Transactional Information Systems 3-48

49 Lessons Learned Equivalence to serial history is a natural correctness criterion CSR, albeit less general than VSR, is most appropriate for complexity reasons its monotonicity property its generalizability to semantically rich operations OCSR and COCSR have additional beneficial properties 4/18/2005 Transactional Information Systems 3-49