Transaction Systems. Andrey Gubichev. October 21, Exercise Session 1

Transcription

1 Transaction Systems Exercise Session 1 Andrey Gubichev October 21, / 45

2 Info This is a theory course about transaction processing and recovery Theory course means... (you will see today) For more implementation-oriented material: see other courses of the chair We will NOT cover: any system-specific (Oracle, DB2, MS SQL etc) info. Read manuals 2 / 45

3 Info Exercise sessions are here to illustrate the material of the course with examples, extra proofs, special cases, etc. Weekly home assignments, to be done individually and submitted via due 9 am every Monday. Written exam at the end 3 / 45

4 Today s plan We will review what typically you should know from the Intro to Databases course This also will be an overview of the core part of the course Disclaimer: all definitions and descriptions are preliminary, they will be re-visited in the course 4 / 45

5 Notation Data objects: x, y, z... Operations of the transaction T i : Read x: ri (x) Write z: wi (z) abort ai commit c i 5 / 45

6 Formal definition of Transaction Transaction T i is a partial ordering of operations with the relation < i such that: T i {r i [x], w i [x] x is a Data object} {a i, c i } ai T i, iff. c i T i If ti is a i or c i, then for all other operations p i : p i < i t i If r i [x] and w i [x] T i, then either r i [x] < i w i [x] or w i [x] < i r i [x] 6 / 45

7 Graphical representation Transaction can be represented as directed acyclic graph (DAG): r 2 [x] w 2 [z] c 2 r 2 [y] r 2 [x] < 2 w 2 [z], w 2 [z] < 2 c 2, r 2 [x] < 2 c 2, r 2 [y] < 2 w 2 [z], r 2 [y] < 2 c 2 Transitive relationships are implicit. 7 / 45

8 Histories (Schedules) More than one transaction can be executed This can be described as a history (schedule): how different transactions are executed next to each other Since different operations of different transactions sometimes may be executed in parallel, a history is a partial order 8 / 45

9 Conflicting operations Conflicting operations can not be executed in parallel, i.e. they have to be ordered Two operations are in conflict, if they both work on the same data item and at least one of them is write operation T i T j r i [x] w i [x] r j [x] w j [x] 9 / 45

10 Definition of History Let T = {T 1, T 2,..., T n } be a set of transactions A history H of T is a partial order with the relation < H, such that n H = i=1 T i <H n i=1 < i For any two conflicting operations p, q H the following holds: p < H q or q < H p 10 / 45

11 Example of history r 2 [x] w 2 [y] w 2 [z] c 2 H = r 3 [y] w 3 [x] w 3 [y] w 3 [z] c 3 r 1 [x] w 1 [x] c 1 11 / 45

12 Serial history A history H is serial if for any two transactions T i and T j in it (i j), all operations of T i are ordered in H before all operations of T j or vice versa r 1 [x] w 1 [x] c 1 r 3 [y] w 3 [x] w 3 [y] w 3 [z] c 3 Or: r 2 [x] w 2 [y] w 2 [z] c 2 r 1 [x]w 1 [x]c 1 r 3 [y]w 3 [x]w 3 [y]w 3 [z]c 3 r 2 [x]w 2 [y]w 2 [z]c 2 12 / 45

13 Serializable histories Serial histories are nice and safe, but potentially slow We want to explore wider class of histories, yet they should be equivalent to some serial history. Such histories are called serializable Two goals: Define what is equivalent How to test equivalence efficiently? 13 / 45

14 Conflict equivalence One possible way to define equivalence of histories Two histories H and H are conflict equivalent (H H ), if: They have the same set of not-aborted transactions (i.e., their operations) They order conflicting operations in the same way The idea is to make sure the computed result is the same 14 / 45

15 Example r 1 [x] w 1 [y] r 2 [z] c 1 w 2 [y] c 2 r 1 [x] r 2 [z] w 1 [y] c 1 w 2 [y] c 2 r 2 [z] r 1 [x] w 1 [y] w 2 [y] c 2 c 1 r 2 [z] r 1 [x] w 2 [y] w 1 [y] c 2 c 1 15 / 45

16 Another Example r 2 [x] w 2 [y] w 2 [z] c 2 H = r 3 [y] w 3 [x] w 3 [y] w 3 [z] c 3 r 1 [x] w 1 [x] c 1 H = r 1 [x]w 1 [x]c 1 r 3 [y]w 3 [x]w 3 [y]w 3 [z]c 3 r 2 [x]w 2 [y]w 2 [z]c 2 16 / 45

17 Conflict serializability Completed prefix C(H) of history H consists of only commited transactions H is conflict serializable if C(H) is conflict equivalent to some serial history H s 17 / 45

18 Testing conflict serializability Conflict graph for history H: Nodes: transactions from H Edges: there is an edge T i to T j if there exist operations p i and p j in conflict and p i < H p j. History H is serializable iff its conflict graph is acyclic. 18 / 45

19 Example History H H = w 1 [x] w 1 [y] c 1 r 2 [x] r 3 [y] w 2 [x] c 2 w 3 [y] c 3 Conflict graph for H T 2 Conflict Graph = T 1 T 3 19 / 45

20 Example(2) H is serializable Possible orderings: H 1 s = T 1 T 2 T 3 H 2 s = T 1 T 3 T 2 H H 1 s H 2 s 20 / 45

21 Example(3) r 1 [x] w 1 [x] w 1 [y] c 1 H = r 2 [x] w 2 [y] c 2 r 3 [x] w 3 [x] c 3 T 3 Conflict Graph = T 2 T 1 21 / 45

22 Example(4) H is serializable Possible orderings H 1 s = T 2 T 1 T 3 H H 1 s 22 / 45

23 Example(5) w 1 [x] w 1 [y] c 1 H = r 2 [x] w 2 [y] c 2 Conflict Graph = T 1 T 2 H is not serializable 23 / 45

24 Other properties of histories Recoverability Avoiding cascading aborts: ACA Strictness 24 / 45

25 Other properties of histories(2) First we define the reads-from relationship Transaction T i reads (data item x) from T j, if w j [x] < r i [x] a j r i [x] If there is wk [x] such that w j [x] < w k [x] < r i [x], then a k < r i [x] Transaction can read from itself 25 / 45

26 Example History H H = w 1 [x] w 1 [y] c 1 r 2 [x] w 3 [y] w 2 [x] c 2 r 3 [y] c 3 T 2 reads from T 1 T 3 reads from itself 26 / 45

27 Recoverability History H is recoverable, if For any TA T i that reads from other TA T j (i j) and c i H, the following holds: c j < c i Transactions should follow a certain commit-order For non-recoverable transactions, there are problems with C and D in ACID 27 / 45

28 Recoverability(2) H = w 1 [x] r 2 [x] w 2 [y] c 2 a 1 H is not recoverable Therefore: When the results of T2 stay, we have inconsistent data (T 2 has read the data from other aborted transaction) (not C) If we discard T2, then the results of commited transaction disappear (not D) 28 / 45

29 Cascading aborts Step T 1 T 2 T 3 T 4 T w 1 [x] 2. r 2 [x] 3. w 2 [y] 4. r 3 [y] 5. w 3 [z] 6. r 4 [z] 7. w 4 [v] 8. r 5 [v] 9. a 1 (abort) 29 / 45

30 Cascading aborts(2) History avoids cascading aborts, if For any Ti that reads from the other TA T j (i j), the following holds: c j < r i [x] Transaction can read only from commited transactions 30 / 45

31 Strictness A History is strict, if For two operations wj [x] < p i [x] (where p i [x] = r i [x] or w i [x]) the following holds: a j < p i [x] or c j < p i [x] History is strict if no data item is read or overwritten until the transaction that wrote it last has ended 31 / 45

32 Hierarchy all histories RC H 9 H 8 SR ACA H 7 ST H 6 H 1 H 2 H 3 H 4 H 5 serial histories SR: serializable, RC: recoverable, ACA: avoids cascading aborts, ST: strict 32 / 45

33 Transaction Scheduler(2) Scheduler is the program that orders operations such that the resulting history is nice (serializable, recoverable) Possibilities after receiving operation: Immediately execute Reject Delay Two strategies: pessimistic and optimistic 33 / 45

34 Pessimistic Scheduler Scheduler delays received operations When there are many operations, scheduler forms the best possible sequence Important representative: Lock-based scheduler 34 / 45

35 Optimistic Scheduler Scheduler tries to execute receieved operations ASAP Sometimes needs to recover from bad situations 35 / 45

36 Lock-based Synchronisation Main idea: Every data item has associated lock Before Ti can access the item, it has to obtain the lock If another Tj has the lock, then T i does not get the lock and has to wait until T j releases the lock hat Only one transaction can hold the lock of a data item How to guarantee serializability? 36 / 45

37 Two-Phase Locking Protocol 2PL Two modes of locks: S (shared, read lock) X (exclusive, write lock) Lock compatibility: Lock held Lock requested no S X S X 37 / 45

38 Rules of locking Every data item to be used by transaction T has to be locked with the corresponding lock mode Transaction can not request the lock that it already holds If the lock can not be granted, transaction has to wait After any lock is released by a transaction, no further locks can be obtained by this transaction (there are 2 phases) At the end of the transaction all the locks have to be released 38 / 45

39 Two Phases #Locks Growing phase Shrinking phase Time Growing phase: locks are obtained but not released Shrinking phase: locks will be released, no further lock can be obtained 39 / 45

40 Example Step T 1 T 2 Note 1. BOT 2. lockx[x] 3. r[x] 4. w[x] 5. BOT 6. locks[x] T 2 has to wait 7. lockx[y] 8. r[y] 9. unlockx[x] T 2 resumes 10. r[x] 11. locks[y] T 2 has to wait 12. w[y] 13. unlockx[y] T 2 resumes 14. r[y] 15. commit 16. unlocks[x] 17. unlocks[y] 18. commit 40 / 45

41 Strict 2PL The second phase is modified: transaction holds all the write locks until the end (commit or abort) 41 / 45

42 Strong 2PL 2PL does not avoid cascading aborts The second phase is modified: transaction holds all the locks until the end (commit or abort) 42 / 45

43 Strong 2PL(2) #Locks EOT Growing phase Time 43 / 45

44 So, homework... Formally prove that all the schedules generated by the Strict2PL scheduler are recoverable List the properties of the following schedules: H1 = w 1 [x]w 2 [x]w 2 [y]w 1 [y]c 2 c 1 H2 = w 1 [x]r 2 [y]r 1 [x]c 1 r 2 [x]w 2 [y]c 2 H 3 = w 1 [x]r 2 [y]r 1 [x]r 2 [x]c 1 w 2 [y]c 2 H 4 = w 1 [x]r 2 [y]r 2 [x]r 1 [x]c 2 w 1 [y]c 1 44 / 45

45 Info Exercises due: 9 AM, October 28, 2013 Submit to andrey.gubichev@in.tum.de Submissions have to be in PDF format Handwritten (and/or scanned) solutions will not be accepted. Use LaTeX (preferable) or Word. 45 / 45