1DT066 Distributed Information System

1. 1DT066Distributed Information System Transactions and Concurrency Control

2. Outline • Motivation • Transaction Concepts • Two Phase Commit • Distributed Transactions and Deadlocks • Summary

3. 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?

4. Balances at t0Acc1: 7500, Acc2: 0 Funds transfer from Acc1 to Acc2: Acc1->debit(7500): Acc1->lock(write); Acc1.balance=0; Acc1->unlock(write); Acc2->credit(7500): Acc2->lock(write); Acc2.balance=7500; Acc2->unlock(write); t0 t1 t2 t3 t4 t5 t6 t7 Time 1 Revisit of Funds Transfer Example

5. Balances at t0Acc1: 7500, Acc2: 0 Funds transfer from Acc1 Funds transfer to Acc2 t0 Acc1->debit(7500): Acc1->lock(write); Acc1.balance=0; Acc1->unlock(write); t1 Acc2->credit(7500): Acc2->lock(write); Acc2.balance=7500; Acc2->unlock(write); t2 t3 t4 t5 t6 t7 Time 1 Funds Transfer in Concurrency

6. 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

7. 2.1.1 Atomicity • 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 2.3 Roles of Components Distributed system components involved in transactions can take role of: • Transactional Client • Transactional Server • Coordinator

13. 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.

14. 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).

15. 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.

16. 2.4 Distributed Transactions (a) Flat transaction (b) Nested transactions M X T 11 X T Client N 1 T T Y 12 T T T 21 T 2 Client Y P Z T 22

17. Begin Trans. Commit Flat Transaction Begin Trans. Begin Trans. Abort Crash Flat Transaction Flat Transaction Rollback Rollback 2.4 Flat Transactions

18. Begin Trans. Commit Main Transaction Call Call Begin Trans. Begin Trans. Commit Commit Call Begin Trans. Commit 2.4 Nested Transactions

19. 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.

20. 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.

21. 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 • ‘DoCommit’ if transaction is to be committed. • Otherwise ‘Abort'. • Servers acknowledge DoCommit once they have committed.

22. 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.

23. 3.2 Recovery in Two-Phase Commit • Failures prior to start of 2PC 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 GetDecision. • If it fails after committing it (re)sends HaveCommitted message.

24. 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.

25. 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.

26. 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.

27. T abort (at M) 11 T provisional commit (at X) 1 T T provisional commit (at N) 12 provisional commit (at N) T 21 aborted (at Y) T 2 T provisional commit (at P) 22 3.3 Example for A Nested Transaction

28. Coordinator of Child Participant Provisional Abort list transaction transactions commit list T T , T yes T , T T , T 1 2 1 12 11 2 T T , T yes T , T T 1 11 12 1 12 11 T T , T no (aborted) T 2 21 22 2 T no (aborted) T 11 11 T T , T T but not T , T 21 12 21 12 21 12 T no (parent aborted) T 22 22 3.3 Information Held by Coordinators

29. 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.

30. 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.

31. 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.

32. 4.1 Interleavings of Two Transactions • 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. T U at X Write (A) Write (B) at Y Read (B) at Y Read (A) at X

33. 4.1 Interleavings of Transactions U, V and W U V W lock D d.deposit(10) at Z lock B b.deposit(10) at Y lock A a.deposit(20) at X lock C c.deposit(30) at Z wait at Y b.withdraw(30) wait at Z c.withdraw(20) wait at X a.withdraw(20)

34. W W Waits for Held by D C A X Z V Held Held by by Waits for U V U Waits for B Held by Y 4.3 Distributed Deadlock (a) (b)

35. local wait-for graph local wait-for graph global deadlock detector T V T T U V U Y X 4.2 Local and Global Wait-For Graphs • 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.

36. W ® ® ® W U V W Held by Waits for Deadlock C detected A Z X Initiation ® ® W U V Waits ® W U for V U Held by Waits for B Y 4.3 Probes Transmitted to Detect Deadlock

37. 4.3 Two Probes Initiated (c) detection initiated at object requested by W (a) initial situation (b) detection initiated at object requested by T T Waits for Waits for T T ® T U ® ® T W V ® ® ® W V T U V U V U V ® ® T U W U ® ® ® T U W V Waits W ® W V for Waits W W for

38. 6 Summary • Transaction concepts: • ACID • Transaction commands • Roles of distributed components in transactions • Two-phase commit • phase one: voting • phase two: completion • Distributed Transactions and Distributed Deadlocks • Read Textbook Chapter 16.