Distributed Transactions Brian Nielsen

Transcription

1 Distributed Transactions Brian Nielsen

2 Transactions SAS Travel reservation Begin_transaction if(reserve(sas.cph2paris)==full) Abort if(reserve(paris.hotel)==full) Abort If(reserve(KLM.Paris2Ams)==full) Abort End_transaction Execute as all-or-noting despite Constraints Concurrency Failures Hotel KLM

3 Transactions Transaction: A sequence of object operations that must be executed with ACID properties Atomicity: the transaction is either performed completely or not at all Consistency: leads from one consistent state to another Isolation: is executed in isolation from other transactions Durability: once completed it is durable Used in Databases and Distributed Systems

4 Transaction Concepts 1. ACID Properties Atomicity Consistency Isolation Durability 2. Transaction Commands: Commit vs. Abort 3. Identify Roles of Distributed Components 4. Flat vs. Nested Transactions

5 Atomicity Transactions are either performed completely or no modification is done. I.e perform successfully every operation in cluster or none is performed Start of a transaction is a continuation point to which it can roll back. End of transaction is next continuation point. Changes to the state are atomic: A jump from the initial state to the result state without any observable intermediate state. - Changes include: Database changes. Messages to outside world. Actions on transducers. (testable / untestable)

6 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. e.g for scenario, consistency means no money is lost : at the end is true, but in between operations may be not Transactions can be aborted if they cannot resolve inconsistencies.

7 Isolation Each transaction accesses resources as if there were no other concurrent transactions. Even though transactions execute concurrently, it appears to the outside observer as if they execute in some serial order. 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.

8 Durability A completed transaction is always persistent (though values may be changed by later transactions). Once a transaction completes successfully (commits), its changes to the state survive failures (what is the failure model? ). - The only way to get rid of what a committed transaction has done is to execute a compensating transaction (which is, sometimes, impossible). Modified resources must be held on persistent storage before transaction can complete. May not just be disk but can include properly batterybacked RAM or the like of EEPROMs.

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

10 Transaction Primitives Primitive BEGIN_TRANSACTION END_TRANSACTION ABORT_TRANSACTION READ WRITE Description Make the start of a transaction Terminate the transaction and try to commit End the transaction and restore the old values Read data from a file, a table, or otherwise Write data to a file, a table, or otherwise

11 Transaction Roles SAS Travel reservation Begin_transaction if(reserve(sas.cph2paris)==full) Abort if(reserve(paris.hotel)==full) Abort If(reserve(KLM.Paris2Ams)==full) Abort End_transaction Transactional Client issues the transaction Transactional Coordinator Controls execution of entire transaction begin / commit / abort Transactional Server executes its operations from transactions commits / aborts these Hotel KLM

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

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

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

15 Execution of a transaction Coordinator interface: opentransaction() -> trans; closetransaction(trans) -> (commit,abort); aborttransaction(trans); Successful opentransaction operation operation operation closetransaction Aborted by client opentransaction operation operation operation aborttransaction server aborts transaction Aborted by server opentransaction operation operation operation ERROR reported to client

16 Reasons for abort A participant may decide to abort a transaction for any reason, especially Logical Constraints (cannot withdraw if negative balance) Conflicts in concurrent execution Deadlock Chrashed or non-responsive participand

17 Bank Example Operations of the Account interface deposit(amount) deposit amount in the account withdraw(amount) withdraw amount from the account getbalance() -> amount return the balance of the account setbalance(amount) set the balance of the account to amount Operations of the Branch interface create(name) -> account create a new account with a given name lookup(name) -> account return a reference to the account with the given name branchtotal() -> amount return the total of all the balances at the branch

18 A banking transaction Transaction T: a.withdraw(100); b.deposit(100); c.withdraw(200); b.deposit(200);

19 Concurrent transactions the lost update problem Transaction T: balance = b.getbalance(); b.setbalance(balance*1.1); a.withdraw(balance/10) balance = b.getbalance(); $200 b.setbalance(balance*1.1); $220 a.withdraw(balance/10) $80 Transaction U: balance = b.getbalance(); b.setbalance(balance*1.1); c.withdraw(balance/10) balance = b.getbalance(); $200 b.setbalance(balance*1.1); $220 c.withdraw(balance/10) $280

20 Concurrent transactions the inconsistent retrievals problem Transaction V: a.withdraw(100) b.deposit(100) a.withdraw(100); $100 b.deposit(100) $300 Transaction W: abranch.branchtotal() total = a.getbalance() $100 total = total+b.getbalance() $300 total = total+c.getbalance()

21 Concurrent transactions serial equivalence If correct transactions are done one at a time in some order, the combined effect will also be correct. A serially equivalent interleaving: An interleaving of the operations of transactions in which the combined effect is the same as if the transactions had been performed one at a time in some order. Serial equivalence prevents lost updates and inconsistent retrievals.

22 A serially equivalent interleaving Transaction T: balance = b.getbalance() b.setbalance(balance*1.1) a.withdraw(balance/10) balance = b.getbalance() $200 b.setbalance(balance*1.1) $220 a.withdraw(balance/10) $80 Transaction U: balance = b.getbalance() b.setbalance(balance*1.1) c.withdraw(balance/10) balance = b.getbalance() $220 b.setbalance(balance*1.1) $242 c.withdraw(balance/10) $278

23 A serially equivalent interleaving Transaction V: a.withdraw(100); b.deposit(100) a.withdraw(100); $100 b.deposit(100) $300 Transaction W: abranch.branchtotal() total = a.getbalance() $100 total = total+b.getbalance() $400 total = total+c.getbalance()...

24 Serializability: Exercise BEGIN_TRANSACTION x = 0; x = x + 1; END_TRANSACTION Schedule 1 Schedule 2 Schedule 3 (a) BEGIN_TRANSACTION x = 0; x = x + 2; END_TRANSACTION (b) x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3; x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3; BEGIN_TRANSACTION x = 0; x = x + 3; END_TRANSACTION (c)???

25 Concurrency Control General organization of managers for handling distributed transactions.

26 Concurrency Control Optimistic Transaction does what it wants and validates changes prior to commit Check if objects have been changed by committed transactions since they were opened Conflicts are rare, maximum concurrency, no deadlocks Re-execute re-conflict. Timestamp based Each transaction T i is given timestamp ts(t i ) If T i wants to do an operation that conflicts with T j Abort Ti if ts(t i ) < ts(t j ) Lock based (most common) Read/write locks acquired on objects 2 phase locking protocol serializability strict 2 phase locking protocol no cascading aborts

27 Two-Phase Locking Two-phase locking.

28 Strict Two-Phase Locking Strict two-phase locking.

29 Deadlocks Deadlock = def Eternal cyclic wait Some schedules may deadlock wait-for graphs Circumventing Deadlocks Prevention Avoidance Detection+Recovery Held by T Waits for T: Lock(a); Lock(b); Lock(b); A B U: Lock(b); Lock(b); Lock(a); Lock(a); Waits for U Held by

30 Atomic Commitment Protocols (ACP) A correct ACP guarantees All the participants that reach a decision, reach the same decision. Decisions are not reversible. A commit decision can only be reached if all participants votes to commit. If there are no failures and all the participants voted to commit, the decision will be commit. At any point, if all failures are repaired, and no new failures are introduced, then all participants eventually reach a decision.

31 2 Phase Commit Unanumously vote for outcome! Voting Phase: Coordinator asks participants for their votes on wheter to abort or commit Decision Phase: If all votes to commit: coordinator sends commit to all If one votes to abort. coordinator send abort to all

32 2PC End_transaction End_transaction C P 1 P 2 P n C CanCommit? P 1 P 2 P n CanCommit?

33 2PC C P 1 P 2 P n Vote: abort C Vote: Commit P 1 P 2 P n Vote: C/A

34 2-Phase Commit C P 1 P 2 P n Decision: abort C Decision: Abort P 1 P 2 P n Decision: A/C

35 Performance of the twophase commit protocol if there are no failures, the 2PC involving N participants requires N cancommit? messages and replies, followed by N docommit messages. the cost in messages is proportional to 3N, and the cost in time is three rounds of messages. The havecommitted messages are not counted there may be arbitrarily many server and communication failures 2PC is is guaranteed to complete eventually, but it is not possible to specify a time limit within which it will be completed delays to participants in uncertain state some 3PCs designed to alleviate such delays they require more messages and more rounds for the normal case

36 Performance of 2PC Assuming N participating servers: 3 message rounds (N-1) Voting requests from coordinator to servers. (N-1) Votes (N-1) Completion requests from coordinator to servers. Thus, Linear: 3(N-1) messages 2PC is is guaranteed to complete eventually, but it is not possible to specify a time bound delays to participants in uncertain state some 3PCs designed to alleviate such delays they require more messages and more rounds for the normal case

37 Recovery of 2PC Role Status Action of recovery manager Coordinator prepared No decision had been reached before the server failed. It sends aborttransaction to all the servers in the participant list and adds the transaction status abortedin its recovery file. Same action for state aborted. If there is no participant list, the participants will eventually timeout and abort the transaction. Coordinator committed A decision to commit had been reached before the server failed. It sends a docommit to all the participants in its participant list (in case it had not done so before) and resumes the two-phase protocol at step 4 (Fig 13.5). Participant committed The participant sends a havecommitted message to the coordinator (in case this was not done before it failed). This will allow the coordinator to discard information about this transaction at the next checkpoint. Participant uncertain The participant failed before it knew the outcome of the transaction. It cannot determine the status of the transaction until the coordinator informs it of the decision. It will send a getdecision to the coordinator to determine the status of the transaction. When it receives the reply it will commit or abort accordingly. Participant prepared Coordinator done The participant has not yet voted and can abort the transaction. No action is required.

38 Transaction Recovery Recovery concerns data durability and failure atomicity. A server keeps data in volatile memory and records committed data in a recovery file. Recovery manager Save data items in permanent storage Restore the server s data items after a crash Reorganize the recovery file for better performance Logging or Shadow versions

39 Recovery manager The task of the Recovery Manager (RM) is: to save objects in permanent storage (in a recovery file) for committed transactions; to restore the server s objects after a crash; to reorganize the recovery file to improve the performance of recovery; to reclaim storage space (in the recovery file). media failures i.e. disk failures affecting the recovery file need another copy of the recovery file on an independent disk. e.g. implemented as stable storage or using mirrored disks we deal with recovery of 2PC separately (at the end) we study logging (13.6.1) but not shadow versions (13.6.2)

40 Recovery Files The recovery files contain sufficient information to ensure the transaction is committed by all the servers. Object Values: <O 1, 4>, <O 2, Hello World >, Intentions list: Transaction ID + a list of data item names and values altered by a transaction. T42: <O 12, 17>, <O 23,37>, When a server prepares to commit, it must first have saved the intentions list in its recovery file Transaction Status Transaction identifier + prepared, committed, or aborted

41 Logging A log contains history of all the transactions performed by a server. The recovery file contains a recent snapshot of the values of all the data items in the server followed by a history of transactions. When a server is prepared to commit, the recovery manager appends all the data items in its intentions list to the recovery file.

42 Log for Banking Service Forward recovery Replay committed transactions from last checkpoint Backward recovery Read log backwards and restore untill all objects restored Eg: P7: U aborted skip P4: T committed restore <A, 96> <B,204> P0: C not restored restore <C,300>

43 Recovery by Logging Recovery of data items Recovery manager is responsible for restoring the server s data items. The most recent information is at the end of the log. A recovery manager gets corresponding intentions list from the recovery file. Reorganizing the recovery file Checkpointing: the process of writing the current committed values (checkpoint) to a new recovery file. Can be done periodically or right after recovery.

44 Shadow Versions Shadow versions technique uses a map to locate versions of the server s data items in a file called a version store. The versions written by each transaction are shadows of the previous committed versions. When prepared to commit, any changed data are appended to the version store. When committing, a new map is made. When complete, new map replaces the old map.

45 Shadow Versions

46 2PC Stable Storage C P 1 P 2 P n Decision: abort C Decision: Abort P 1 P 2 P n Write to stable storage Participant: If YES: records vote and object updates in permanent storage, and then votes IF NO: aborts (discards or undo es updates), and votes Coordinator Records vote, sends it to all participants Decision: A/C

47 2PC - Failures C P 1 P 2 P n 1. CanCommit message lost Timeout and abort 2. Vote message lost Coordinator times out and aborts 3. Decision message lost Yes voting participant uncertain! Ask coordinator or other participants about verdict 4. Crash Participant: prepared Coordinator times out and aborts 5. Crash Participant: After Abort Abort 6. Crash Participant: After Yes Participant uncertain! Ask coordinator or other participants about verdict when rebooted 7. Crash Coordinator: Before or after decision Yes voting participants uncertain Elect new coordinator (CAREFULL!)

48 2.2 Log and 2PC Trans:T Coord r:t Trans:T Trans: U Part pant:u Trans:U Trans: U prepared part pant list:... committed prepared Coord r:.. uncertain committed intentions list list intentions

49 Summary of transaction recovery Transaction-based applications have strong requirements for the long life and integrity of the information stored. Transactions are made durable by performing checkpoints and logging in a recovery file, which is used for recovery when a server is replaced after a crash. Users of a transaction service would experience some delay during recovery. It is assumed that the servers of distributed transactions exhibit crash failures and run in an asynchronous system, but they can reach consensus about the outcome of transactions because crashed servers are replaced with new processes that can acquire all the relevant information from permanent storage or from other servers

50 Failure model for the commit protocols Recall the failure model for transactions in Chapter 12 this applies to the two-phase commit protocol Commit protocols are designed to work in asynchronous system (e.g. messages may take a very long time) servers may crash messages may be lost. assume corrupt and duplicated messages are removed. no byzantine faults servers either crash or they obey their requests 2PC is an example of a protocol for reaching a consensus. Chapter 11 says consensus cannot be reached in an asynchronous system if processes sometimes fail. however, 2PC does reach consensus under those conditions. because crash failures of processes are masked by replacing a crashed process with a new process whose state is set from information saved in permanent storage and information held by other processes.

51 Nested transactions (a) Flat transaction (b) Nested transactions In a nested transaction, the toplevel transaction can open subtransactions, and each subtransaction can open further subtransactions down to any depth of nesting T Client In the nested case, Z subtransactions at the same level can run concurrently, so T1 and T2 are concurrent, and as they invoke objects in different servers, they can run in parallel. T X Y Client T T 1 T 2 Figure 13.1 X Y T 11 T 12 T 21 T 22 A flat client transaction completes each of its requests before going on to the next one. Therefore, each transaction accesses servers objects sequentially M P N

52 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. Hierarchical versions of 2PC

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

54 Nested transactions T : top-level transaction T 1 = opensubtransaction T 2 = opensubtransaction T 1 : T 2 : opensubtransaction opensubtransaction T 11 : T 12 : prov. commit prov. commit prov. commit T 21 : opensubtransaction opensubtransaction T 211 : prov. commit prov.commit commit abort

55 CORBA Transaction Service Application Objects Object Request Broker Transaction CORBA facilities CORBA services

56 IDL Interfaces Object Transaction Service defined through three IDL interfaces: Current Coordinator Resource

57 Current interface Current { void begin() raises (...); void commit (in boolean report_heuristics) raises (NoTransaction, HeuristicMixed, HeuristicHazard); void rollback() raises(notransaction); Status get_status(); string get_transaction_name(); Coordinator get_control(); Coordinator suspend(); void resume(in Coordinator which) raises(invalidcontrol); };

58 Coordinator interface Coordinator { Status get_status(); Status get_parent_status(); Status get_top_level_status(); boolean is_same_transaction(in Coordinator tr); boolean is_related_transaction(in Coordinator tr); RecoveryCoordinator register_resource( in Resource r) raises(inactive); void register_subtran_aware( in SubtransactionAwareResource r) raises(inactive, NotSubtransaction);... };

59 Resource interface Resource { }; Vote prepare(); void rollback() raises(...); void commit() raises(...); void commit_one_phase raises(...); void forget(); interface SubtransactionAwareResource:Resource { }; void commit_subtransaction(in Coordinator p); void rollback_subtransaction();

60 END