Distributed Systems Topic 7 Transactions and Distributed Transactions

Distributed Systems Topic 7: Transactions and Distributed Transactions Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong © Chinese University, CSE Dept. Distributed Systems / 7 - 1

Outline 1 Motivation 2 Transaction Concepts 3 Two Phase Commit 4 Distributed Transactions and Deadlocks 5 Summary © Chinese University, CSE Dept. Distributed Systems / 7 - 2

1 Motivation ¨ What happens if a failure occurs during modification of resources? ¨ Which operations have been completed? ¨ Which operations have not (and have to be done again)? ¨ In which states will the resources be? © Chinese University, CSE Dept. Distributed Systems / 7 - 3

1 Revisit of Funds Transfer Example Balances at t 0 Acc 1: 7500, Acc 2: 0 Funds transfer from Acc 1 to Acc 2: t 0 t 1 t 2 t 3 t 4 t 5 t 6 t 7 Acc 1 ->debit(7500): Acc 1 ->lock(write); Acc 1. balance=0; Acc 1 ->unlock(write); Acc 2 ->credit(7500): Acc 2 ->lock(write); Acc 2. balance=7500; Acc 2 ->unlock(write); Time © Chinese University, CSE Dept. Distributed Systems / 7 - 4

1 Funds Transfer in Concurrency Balances at t 0 Acc 1: 7500, Acc 2: 0 t 1 t 2 t 3 t 4 t 5 t 6 Funds transfer from Acc 1 Funds transfer to Acc 2 Acc 1 ->debit(7500): Acc 1 ->lock(write); Acc 2 ->credit(7500): Acc 1. balance=0; Acc 2 ->lock(write); Acc 1 ->unlock(write); Acc 2. balance=7500; Acc 2 ->unlock(write); t 7 Time © Chinese University, CSE Dept. Distributed Systems / 7 - 5

2 Transaction Concepts 1 ACID Properties – Atomicity – Consistency – Isolation – Durability 2 Transaction Commit vs. Abort 3 Roles of Distributed Components 4 Flat vs. Nested Transactions © Chinese University, CSE Dept. Distributed Systems / 7 - 6

2. 1. 1 Atomicity ¨ Transactions are sequences of operations that are clustered together. ¨ Transactions are either performed completely or no modification is done. ¨ Start of a transaction is a continuation point to which it can roll back. ¨ End of transaction is next continuation point. © Chinese University, CSE Dept. Distributed Systems / 7 - 7

2. 1. 2 Consistency ¨ Shared resources should always be consistent. ¨ Inconsistent states occur during transactions: – hidden for concurrent transactions – to be resolved before end of transaction. ¨ Application defines consistency and is responsible for ensuring it is maintained. ¨ Transactions can be aborted if they cannot resolve inconsistencies. © Chinese University, CSE Dept. Distributed Systems / 7 - 8

2. 1. 3 Isolation ¨ Each transaction accesses resources as if there were no other concurrent transactions. ¨ Modifications of the transaction are not visible to other resources before it finishes. ¨ Modifications of other transactions are not visible during the transaction at all. ¨ Implemented through: – two-phase locking or – optimistic concurrency control. © Chinese University, CSE Dept. Distributed Systems / 7 - 9

2. 1. 4 Durability ¨ A completed transaction is always persistent (though values may be changed by later transactions). ¨ Modified resources must be held on persistent storage before transaction can complete. ¨ Wide use of hard disks. © Chinese University, CSE Dept. Distributed Systems / 7 - 10

2. 2 Transaction Commands ¨ Begin: – Start a new transaction. ¨ Commit: – End a transaction. – Store changes made during transaction. – Make changes accessible to other transactions. ¨ Abort: – End a transaction. – Undo all changes made during the transaction. © Chinese University, CSE Dept. Distributed Systems / 7 - 11

2. 3 Roles of Components Distributed system components involved in transactions can take role of: ¨Transactional Client ¨Transactional Server ¨Coordinator © Chinese University, CSE Dept. Distributed Systems / 7 - 12

2. 3. 1 Coordinator ¨ Coordinator plays key role in managing transaction. ¨ Coordinator is the component that handles begin / commit / abort transaction calls. ¨ Coordinator allocates system-wide unique transaction identifier. ¨ Different transactions may have different coordinators. © Chinese University, CSE Dept. Distributed Systems / 7 - 13

2. 3. 2 Transactional Server ¨ Every component with a resource accessed or modified under transaction control. ¨ Transactional server has to know coordinator. ¨ Transactional server registers its participation in a transaction with the coordinator. ¨ Transactional server has to implement a transaction protocol (two-phase commit). © Chinese University, CSE Dept. Distributed Systems / 7 - 14

2. 3. 3 Transactional Client ¨ Only sees transactions through the transaction coordinator. ¨ Invokes services from the coordinator to begin, commit and abort transactions. ¨ Implementation of transactions are transparent for the client. ¨ Cannot tell difference between server and transactional server. © Chinese University, CSE Dept. Distributed Systems / 7 - 15

2. 4 Distributed Transactions (a) Flat transaction (b) Nested transactions M X T 11 X Client T Y T T 1 N T 12 T T 21 T 2 Client Y Z P T 22 © Chinese University, CSE Dept. Distributed Systems / 7 - 16

2. 4 Flat Transactions Begin Trans. Commit Flat Transaction Begin Trans. Crash Flat Transaction Rollback © Chinese University, CSE Dept. Begin Trans. Abort Flat Transaction Rollback Distributed Systems / 7 - 17

2. 4 Nested Transactions Begin Trans. Commit Main Transaction Call Begin Trans. Commit © Chinese University, CSE Dept. Distributed Systems / 7 - 18

3 Two-Phase Commit ¨ Multiple autonomous distributed servers: – For a commit, all transactional servers have to be able to commit. – If a single transactional server cannot commit its changes every server has to abort. ¨ Single phase protocol is insufficient. ¨ Two phases are needed: – Phase one: Voting – Phase two: Completion. © Chinese University, CSE Dept. Distributed Systems / 7 - 19

3. 1 Phase One ¨ Called the voting phase. ¨ Coordinator asks all servers if they are able (and willing) to commit. ¨ Servers reply: – Yes: it will commit if asked, but does not yet know if it is actually going to commit. – No: it immediately aborts its operations. ¨ Hence, servers can unilaterally abort but not unilaterally commit a transaction. © Chinese University, CSE Dept. Distributed Systems / 7 - 20

3. 1 Phase Two ¨ Called the completion phase. ¨ Co-ordinator collates all votes, including its own, and decides to – commit if everyone voted ‘Yes’. – abort if anyone voted ‘No’. ¨ All voters that voted ‘Yes’ are sent – ‘Do. Commit’ if transaction is to be committed. – Otherwise ‘Abort'. ¨ Servers acknowledge Do. Commit once they have committed. © Chinese University, CSE Dept. Distributed Systems / 7 - 21

3. 1 Server Uncertainty ¨ Period when a server must be able to commit, but does not yet know if has to. ¨ This period is known as server uncertainty. ¨ Usually short (time needed for coordinator to receive and process votes). ¨ However, failures can lengthen this process, which may cause problems. © Chinese University, CSE Dept. Distributed Systems / 7 - 22

3. 2 Recovery in Two-Phase Commit ¨ Failures prior to start of 2 PC results in abort. ¨ Coordinator failure prior to transmitting commit messages results in abort. ¨ After this point, coordinator will retransmit all commit messages on restart. ¨ If server fails prior to voting, it aborts. ¨ If it fails after voting, it sends Get. Decision. ¨ If it fails after committing it (re)sends Have. Committed message. © Chinese University, CSE Dept. Distributed Systems / 7 - 23

3. 2 Complexity Assuming N participating servers: ¨ (N-1) Voting requests from coordinator to servers. ¨ (N-1) Votes from servers to coordinator. ¨ At most (N-1) Completion requests from coordinator to servers. ¨ (When commit) (N-1) acknowledgement from servers to coordinator. ¨ Hence, complexity of requests is linear in the number of participating servers. © Chinese University, CSE Dept. Distributed Systems / 7 - 24

3. 3 Committing Nested Transactions ¨ Cannot use same mechanism to commit nested transactions as: – subtransactions can abort independent of parent. – subtransactions must have made decision to commit or abort before parent transaction. ¨ Top level transaction needs to be able to communicate its decision down to all subtransactions so they may react accordingly. © Chinese University, CSE Dept. Distributed Systems / 7 - 25

3. 3 Provisional Commit ¨ Subtransactions vote either: – aborted or – provisionally committed. ¨ Abort is handled as normal. ¨ Provisional commit means that coordinator and transactional servers are willing to commit subtransaction but have not yet done so. © Chinese University, CSE Dept. Distributed Systems / 7 - 26

3. 3 Example for A Nested Transaction T 11 T 1 provisional commit (at X) T T provisional commit (at N) T 21 provisional commit (at N) T provisional commit (at P) 12 T 2 aborted (at Y) 22 © Chinese University, CSE Dept. abort (at M) Distributed Systems / 7 - 27

3. 3 Information Held by Coordinators Coordinator of transaction T T 1 T 2 T 11 T 12 , T 21 T 22 Child transactions T 1, T 2 T 11 , T 12 T 21 , T 22 © Chinese University, CSE Dept. Participant Provisional commit list T 1, T 12 yes no (aborted) T 12 but not T 21 , T 12 no (parent aborted)T 22 Abort list T 11 , T 2 T 11 Distributed Systems / 7 - 28

3. 3 Two-Phase Commit for Nested Transactions ¨ For nested transactions, the top-level transaction plays as coordinator, while participants are all the provisionally committed subtransaction coordinators without aborted ancestors. ¨ Hierarchic two-phase commit: a multi-level nested protocol where the coordinator communicates to the immediate child transaction coordinator in a hierarchic fashion. ¨ Flat two-phase commit: the coordinator contact all participants with provisional commit directly. © Chinese University, CSE Dept. Distributed Systems / 7 - 29

3. 3 Locking and Provisional Commits ¨ Locks cannot be released after provisional commit. ¨ Data items remain ‘protected’ until top-level transaction commits. ¨ This may reduce concurrency. ¨ Interactions between sibling subtransactions: – should they be prevented as they are different? – allowed as they are part of the same transaction? ¨ Generally they are prevented. © Chinese University, CSE Dept. Distributed Systems / 7 - 30

4 Distributed Transactions and Deadlocks ¨ In distributed transactions, each server is responsible for applying concurrency control to its own objects, and all the servers jointly ensure the concurrent transactions are performed in a serially equivalent manner. ¨ This means interleavings of two transactions have to be serially equivalent both locally at each server and globally. © Chinese University, CSE Dept. Distributed Systems / 7 - 31

4. 1 Interleavings of Two Transactions T Write (A) U at X Write (B) Read (B) at Y Read (A) at X ¨ Transaction T before Transaction U on server X ¨ Transaction U before Transaction T on server Y ¨ This is not serially equivalent globally since T before U in one server and U before T in another. © Chinese University, CSE Dept. Distributed Systems / 7 - 32

4. 1 Interleavings of Transactions U, V and W U d. deposit(10) a. deposit(20) b. withdraw(30) V lock D at Z b. deposit(10) lock A at X W lock B at Y c. deposit(30) lock C at Z a. withdraw(20) wait at X wait at Y c. withdraw(20) © Chinese University, CSE Dept. wait at Z Distributed Systems / 7 - 33

4. 2 Distributed Deadlock: Wait-For Graphs (a) (b) W Held by D C A X Z Waits for W Waits for V Held by V U U Waits for B Held by Y © Chinese University, CSE Dept. Distributed Systems / 7 - 34

4. 2 Local and Global Wait-For Graphs local wait-for graph T U X local wait-for graph V global deadlock detector T T Y U V • Phantom deadlock: A deadlock that is “detected” but is not really a deadlock is called a phantom deadlock. • E. g. : Transaction U releases an object at server X and requests the one held by V at server Y. Assuming the latter is first received. © Chinese University, CSE Dept. Distributed Systems / 7 - 35

4. 3 Probes Transmitted to Detect Deadlock W W® U ® V ® W Held by Waits for Deadlock detected C A Z W® U ® V Waits for Initiation W® U V Edge-chasing algorithm: 1. initiation Held by 2. detection 3. resolution © Chinese University, CSE Dept. X U Y B Waits for Distributed Systems / 7 - 36

4. 3 Two Probes Initiated (a) initial situation Waits for V Waits for T U W (c) detection initiated at object requested by W (b) detection initiated at object requested by T Waits for T V ®U W U T®U®W®V T®U®W ®V ® T W V ®V®T®U U W W © Chinese University, CSE Dept. T T ®V W Waits for Distributed Systems / 7 - 37

5 Summary ¨ Transaction concepts: – ACID properties – Transaction commands – Roles of distributed components in transactions ¨ Two-phase commit – Phase one: voting – Phase two: completion ¨ Distributed Transactions and Distributed Deadlocks – Distributed transactions and their interleavings – Distributed deadlocks and the detectors ¨ Read Textbook Chapter 16. 2, 16. 3, and 17. © Chinese University, CSE Dept. Distributed Systems / 7 - 38