Exercise 11: Transactions

Size: px

Start display at page:

Download "Exercise 11: Transactions"

Rolf Leonard
5 years ago
Views:

1 Data Modelling and Databases (DMDB) ETH Zurich Spring Semester 2017 Systems Group Lecturer(s): Gustavo Alonso, Ce Zhang Date: Assistant(s): Claude Barthels, Eleftherios Sidirourgos, Eliza Last update: August 16, 2017 Wszola, Ingo Müller, Kaan Kara, Renato Marroquín, Zsolt István Exercise 11: Transactions Solution The exercises marked with * will be discussed in the exercise session. You can solve the other exercises as practice, ask questions about them in the session, and hand them in for feedback. All exercises may be relevant for the exam. Ask Kaan (kaan.kara@inf.ethz.ch) for feedback on this week s exercise sheet or give it to the TA of your session (preferably stapled and with your address). 1 Serializability* Consider the following two transactions: T1 read(a); A:=A-N; write(a); read(b); B:=B+N; write(b); T2 read(a); A := A+M; write(a); Below are all possible transaction schedules(histories) for the two transactions. We omit the operations that only change the local state (e.g. assignments to local variables). Furthermore, r i (A) denotes a read operation on A of transaction T i and w j (B) denotes a write operation on B of transaction T j. Decide for each history if it is serializable and give a possible serialization order. Also point out why the not serializable histories are so.

2 History Serialization H 1 r 2 (A), w 2 (A), r 1 (A), w 1 (A), r 1 (B), w 1 (B) T 2, T 1 H 2 r 1 (A), w 1 (A), r 1 (B), w 1 (B), r 2 (A), w 2 (A) T 1, T 2 H 3 r 1 (A), w 1 (A), r 2 (A), w 2 (A), r 1 (B), w 1 (B) T 1, T 2 H 4 r 1 (A), w 1 (A), r 2 (A), r 1 (B), w 2 (A), w 1 (B) T 1, T 2 H 5 r 1 (A), w 1 (A), r 2 (A), r 1 (B), w 1 (B), w 2 (A) T 1, T 2 H 6 r 1 (A), w 1 (A), r 1 (B), r 2 (A), w 2 (A), w 1 (B) T 1, T 2 H 7 r 1 (A), w 1 (A), r 1 (B), r 2 (A), w 1 (B), w 2 (A) T 1, T 2 H 8 r 2 (A), r 1 (A), w 2 (A), w 1 (A), r 1 (B), w 1 (B) not serializable H 9 r 2 (A), r 1 (A), w 1 (A), w 2 (A), r 1 (B), w 1 (B) not serializable H 10 r 2 (A), r 1 (A), w 1 (A), r 1 (B), w 2 (A), w 1 (B) not serializable H 11 r 2 (A), r 1 (A), w 1 (A), r 1 (B), w 1 (B), w 2 (A) not serializable H 12 r 1 (A), r 2 (A), w 2 (A), w 1 (A), r 1 (B), w 1 (B) not serializable H 13 r 1 (A), r 2 (A), w 1 (A), w 2 (A), r 1 (B), w 1 (B) not serializable H 14 r 1 (A), r 2 (A), w 1 (A), r 1 (B), w 2 (A), w 1 (B) not serializable H 15 r 1 (A), r 2 (A), w 1 (A), r 1 (B), w 1 (B), w 2 (A) not serializable Explanation: The trivial histories H 1, H 2 are the ones where the transactions T 1 and T 2 are executed consecutively. Histories H 8,..., H 15 are not serializable because of circular dependencies in the serializability graph. In H 8, for instance, r 1 (A), w 2 (A) indicates that T 1 T 2, however, the subsequent operations w 2 (A), w 1 (A) indicate that T 2 T 1. 2 Read Only Transactions* Which of the following statements are true? Note: A previous version of this exercise sheet had slightly different answers. They have been rewritten for clarification. Transactions do not need to be isolated in databases where a majority of applications are read-only and a minority of applications perform updates. Note: An earlier version of the exercise sheet said Transactions can be omitted in databases, where.... If transactions are not isolated from one another, lost updates might occur for mixed read-write applications. Note: An earlier version of the exercise sheet said If transactions are omitted,.... A history with only read operations is always serializable. When determining the serializability of a history, only the fact whether transactions write or not is important, no matter which objects the different transactions write. Note: An earlier version of the exercise sheet said..., the objects on which the operations are applied do not matter.

3 Explanation: In general, read operations are not in conflict. Therefore, in read-only application there is no need for synchronization (i.e. the history is always serializable). However, a write operation conflicts with all read operations that read the same data object. Readonly applications could read insertions or updates of write operations that finally abort, i.e., they could see phantom values or make uncommitted reads. 3 Recoverability and Serialization Notation used in this exercise: r i (A) - Transaction i reads data object A. w i (A) - Transaction i writes to data object A. c i - Transaction i commits. a i - Transaction i aborts. Every history can be ordered in two classes relative to recoverability and serializability: If a Transaction T2 writes to a data location A, which T1 later reads, then a history is: i Recoverable if c 2 < H c 1 ii Avoiding Cascading Abort (ACA) if c 2 < H r 1 (A) iii Strict if c 2 < H o 1 (A) where o 1 (A) is a read or write 1. Complete the following table. Indicate the class and provide the serialization order, if it applies.*

4 History Class 1 w 2 (A) r 1 (A) c 1 c 2 not recoverable, T 2, T 1 2 w 2 (A) r 1 (A) c 1 a 2 not recoverable, serializable (see comments) 3 w 2 (A) r 1 (A) a 2 a 1 recoverable, serializable (see comments) 4 w 2 (A) c 2 r 1 (A) c 1 strict, T 2, T 1 5 w 1 (A) w 2 (A) c 2 c 1 ACA, T 1, T 2 6 r 2 (A) w 1 (A) w 2 (A) c 2 c 1 ACA, not serializable 7 w 2 (A) w 3 (A) a 3 r 1 (A) c 2 c 1 recoverable, T 2, T 3, T 1 8 w 1 (A) r 2 (B) c 1 w 2 (A) c 2 strict, T 1, T 2 9 w 1 (A) r 2 (B) w 1 (B) c 1 w 2 (A) c 2 strict, not serializable Explanation: Note that the statements in the question about recoverable histories are not complete definitions. They are helpful to find out the degree of recoverability of some of the histories; for others, the definitions of the lecture are needed. 2-3: Serialization only considers non-aborted transactions, so these histories are indeed serializable and either order is right. 5: not strict because T 1 does not commit before T 2 writes. 9: not serializable because: r 2 (B) < H w 1 (B) but w 1 (A) < H w 2 (A) 2. For each of the following histories indicate the most strict recoverability class and one possible serialization order if the history is serializable. History 1 w 1 (A) r 2 (B) w 1 (B) c 1 w 2 (A) c 2 2 r 2 (A) r 1 (A) w 1 (A) r 1 (B) w 1 (B) w 2 (A) c 1 c 2 3 w 2 (B) w 1 (A) r 2 (A) w 2 (A) c 2 c 1 4 w 3 (A) w 2 (A) c 3 w 1 (A) r 1 (B) w 2 (A) c 2 w 1 (B) 5 w 2 (A) w 1 (A) r 2 (A) w 2 (A) c 1 c 2 6 w 1 (A) w 2 (A) r 2 (A) w 2 (A) c 2 r 1 (A) c 1 7 w 2 (A) r 1 (A) w 3 (A) a 3 c 2 c 1 8 r 2 (C) w 1 (A) r 2 (B) w 1 (B) c 1 w 2 (C) c 2 History Not Rec Rec ACA Strict Serialization Order Not Serializable 1 X X 2 X X 3 X T 1, T 2 4 X X 5 X X 6 X X 7 X T 2, T 3, T 1 or T 2, T 1, T 3 or T 3, T 2, T 1 8 X T 2, T 1

5 Explanation: Recoverability: 1. T 2 overwrites A from T 1, but T 1 commits before this happens, i.e., c 1 < w 2 (A), and no other value is read from or overwritten by another transaction, so the history is strictly recoverable. 2. No transaction reads from the other one, so the history avoids cascading aborts, but T 2 overwrites A from T 1 and c 1 w 2 (A), so the history is not strictly recoverable. 3. T 2 reads A from T 1, but c 1 c 2, so the history is not recoverable. 4. No transaction reads from the other one, so the history avoids cascading aborts, but T 2 overwrites A from T 3 and c 3 w 2 (A), so the history is not strictly recoverable. 5. T 2 reads A from T 1 and c 1 < c 2 (and no transaction reads anything else from another transaction), so the history is recoverable. However, c 1 r 2 (A), so the history does not avoid cascading aborts. 6. T 1 reads A from T 2 and c 2 < r 1 (A). Since no transaction reads anything else from another transaction (T 2 reads its own value of A, not the previous one of T 1 ), the history avoids cascading aborts. 7. T 1 reads A from T 2 and c 2 < c 1 (and no transaction reads anything else from another transaction), so the history is recoverable. However, c 2 r 1 (A), so the history does not avoid cascading aborts. 8. No transaction reads or overwrites values from other transactions, so the history is strictly recoverable. Serializability: 1. Transaction T 1 depends on transaction T 2, i.e., T 2 T 1 (hence T 2 needs to be executed before T 1 ), because r 2 (B) and w 1 (B) conflict and are executed in this order, i.e., r 2 (B) w 1 (B); but also T 2 depens on T 1 because w 1 (A) and w 2 (A) conflict. Therefor, the dependency graph has a circle; the history cannot be serialized. 2. T 2 T 1 because r 2 (A) w 1 (A); but also T 1 T 2 because r 1 (A) w 2 (A). 3. The only conflict is w 1 (A) with r 2 (A) (and w 2 (A)), which can be serialized. 4. T 1 neither commits nor aborts. In the lecture, equivalence of histories is defined on non-aborted transactions, of which T 1 is part. In this case T 2 T 1 because w 2 (A) w 1 (A); but also T 1 T 2 because w 1 (A) w 2 (A). We accept a second answer using the definition of equivalence of Bernstein et al., 1 which is only based on the committed transactions. T 1 is thus not taken into account and the only dependency is T 3 T 2 (because w 3 (A) w 1 (A)), so any serialization order with T 3 < T 2 is equivalent to the original history. 5. T 2 T 1 because w 2 (A) w 1 (A); but also T 1 T 2 because w 1 (A) r 2 (A). 6. T 1 T 2 because w 1 (A) w 2 (A); but also T 2 T 1 because w 2 (A) r 1 (A).

6 7. T 3 gets aborted and is thus not relevant for serializability (histories are defined equivalent if conflicting operations of their non-aborted transactions are ordered the same way). The only dependency is T 2 T 1 (because w 2 (A) r 1 (A)), so the transactions can be serialized. 8. The only dependency is T 2 T 1 (because r 2 (B) w 1 (B)), so the transactions can be serialized. 4 2PL and Snapshot Isolation Notation used in this exercise: b i - Begin of transaction i r i (A) - Transaction i reads data object A. w i (A) - Transaction i writes to data object A. c i - Transaction i commits successfully. a i - Transaction i aborts or is aborted. 1. Determine if the following histories are possible under snapshot isolation (SI), strict twophase locking (S2PL), or both.* History SI S2PL b 1 r 1 (A) w 1 (B) b 2 w 2 (A) r 2 (B) b 3 c 2 r 3 (A) c 1 c 3 X b 1 r 1 (A) b 2 r 2 (A) w 2 (B) c 2 w 1 (A) c 1 X X b 1 w 1 (B) r 1 (A) b 2 w 2 (B) c 1 a 2 X b 1 w 1 (A) b 2 r 1 (B) r 2 (B) c 1 w 2 (A) c 2 X Explanation: History 1: T 2 cannot write A, while T 1 has a read lock on A. (op. 5 vs op. 2). History 3: T 2 cannot write B, while T 1 has a write lock on B. (op. 5 vs op. 2). History 4: T 2 cannot successfully commit because both transactions write A. (op. 2 vs op. 7). 2. Can phantoms occur in snapshot isolation? (Explain the answer in one or two sentences) Solution: No. In snapshot isolation, a query will not see any updates performed after it has started and, thus, phantoms cannot occur. 3. In Two Phase Locking (2PL), one can release all locks at the point when the transaction has finished but has not issued a commit. Will the result be serializable?

7 Yes No Solution: Yes, the 2PL property is preserved. Are histories generated by this approach always recoverable? Yes No Solution: No, histories can be non recoverable because of accessing uncommitted data. 4. Using two conflicting transactions: T 1 : r 1 (A) w 1 (B) c 1 T 2 : r 2 (B) w 2 (A) c 2 Find a history with c 1 < c 2 (i.e. T 1 commits before T 2 ) and which corresponds to the serial execution T 2, T 1. Solution: r 2 (B), w 2 (A), r 1 (A), w 1 (B), c 1, c 2 Is this history possible under Two Phase Locking (2PL) and Strict Two Phase Locking (S2PL)? 2PL S2PL Yes X No X Explanation: With S2PL the locks can only be released after the transaction has been committed. 5 ACID Why do systems check integrity constraints only at the end of a transaction? Also indicate the ACID-property that is fulfilled by this and explain why. 1. Atomicity 2. Consistency X

8 3. Isolation 4. Durability Explanation: The integrity constraints are only checked at the end of a transaction, because during the lifetime of a transaction the database could be in an inconsistent state. A transaction should transform a consistent database state to another consistent database state. 6 ACID II* The following is a true story. On May 30th 2009, an ETH professor flew from Zurich to San Fransisco via Munich. At the Munich airport, there are electronic barriers equipped with barcode readers. At the gate, the passengers insert their boarding pass into the bar-code reader, the barrier opens, the passenger can pass and the barrier closes. Unfortunately, just when the professor inserted his boarding pass, the electronic barrier broke down. Hence, he tried again at a different barrier, only to find out that he was rejected because the same boarding pass had allegedly already been used. Nonetheless, the staff let the professor enter the airplane. Later on, when the professor was already seated in the airplane, enjoying a cool drink, it was announced that the take-off was delayed for 30 minutes: Some passenger s luggage had to be removed from the airplane, because he or she apparently had not boarded the airplane. It was only in San Fransisco that the professor realized that it was actually his luggage that was removed from the airplane. This only happened because an important principle of transaction management was violated. Which one is it? Solution: Atomicity: the last part of the transaction (passing the barrier) was not executed but still the transaction was committed to the database.

Exercise 12: Commit Protocols and Replication

Exercise 12: Commit Protocols and Replication Data Modelling and Databases (DMDB) ETH Zurich Spring Semester 2017 Systems Group Lecturer(s): Gustavo Alonso, Ce Zhang Date: May 22, 2017 Assistant(s): Claude Barthels, Eleftherios Sidirourgos, Eliza