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

2. © Chinese University, CSE Dept. Distributed Systems / 11 - 2 Outline 1 Motivation 2 Transaction Concepts 3 Two phase Commit 4 Transaction Recovery 5 CORBA Transaction Service 6 Summary

3. © Chinese University, CSE Dept. Distributed Systems / 11 - 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. © Chinese University, CSE Dept. Distributed Systems / 11 - 4 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

5. © Chinese University, CSE Dept. Distributed Systems / 11 - 5 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.

6. © Chinese University, CSE Dept. Distributed Systems / 11 - 6 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.

7. © Chinese University, CSE Dept. Distributed Systems / 11 - 7 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.

8. © Chinese University, CSE Dept. Distributed Systems / 11 - 8 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.  May not just be disk but can include properly battery-backed RAM or the like of EPROMs.

9. © Chinese University, CSE Dept. Distributed Systems / 11 - 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. © Chinese University, CSE Dept. Distributed Systems / 11 - 10 2.3 Roles of Components Distributed system components involved in transactions can take role of:  Transactional Client  Transactional Server  Coordinator

11. © Chinese University, CSE Dept. Distributed Systems / 11 - 11 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.

12. © Chinese University, CSE Dept. Distributed Systems / 11 - 12 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).

13. © Chinese University, CSE Dept. Distributed Systems / 11 - 13 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.

14. © Chinese University, CSE Dept. Distributed Systems / 11 - 14 2.4 Flat Transactions

15. © Chinese University, CSE Dept. Distributed Systems / 11 - 15 2.4 Nested Transactions Main Transaction Call Commit Begin Trans. Begin Trans. Commit Begin Trans. Commit Begin Trans. Commit

16. © Chinese University, CSE Dept. Distributed Systems / 11 - 16 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.

17. © Chinese University, CSE Dept. Distributed Systems / 11 - 17 3 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.

18. © Chinese University, CSE Dept. Distributed Systems / 11 - 18 3 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.

19. © Chinese University, CSE Dept. Distributed Systems / 11 - 19 3 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.

20. © Chinese University, CSE Dept. Distributed Systems / 11 - 20 3 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.

21. © Chinese University, CSE Dept. Distributed Systems / 11 - 21 3 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.

22. © Chinese University, CSE Dept. Distributed Systems / 11 - 22 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.

23. © Chinese University, CSE Dept. Distributed Systems / 11 - 23 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.

24. © Chinese University, CSE Dept. Distributed Systems / 11 - 24 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.

25. © Chinese University, CSE Dept. Distributed Systems / 11 - 25 4 Transaction Recovery  Recovery concerns data durability (permanent and volatile data) 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 –reclaim storage space (in the recovery file)

26. © Chinese University, CSE Dept. Distributed Systems / 11 - 26 4 Intentions List  An intentions list of a server is a list of data item names and values altered by a transaction.  The server uses the intentions list when a transaction commits or aborts.  When a server prepares to commit, it must have saved the intentions list in its recovery file.  The recovery files contain sufficient information to ensure the transaction is committed by all the servers.

27. © Chinese University, CSE Dept. Distributed Systems / 11 - 27 Type of entryDescription of contents of entry Object A value of an object Transaction statusTransaction identifier, transaction status (prepared, committed, aborted) and other status values used for two-phase commit Intentions listTransaction identifier and a sequence of intentions, each of which consists of, 4 Entries in Recovery File

28. © Chinese University, CSE Dept. Distributed Systems / 11 - 28 4.1 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 recover manager appends all the data items in its intentions list to the recovery file.  The recovery manager associates a unique identifier with each data item.

29. © Chinese University, CSE Dept. Distributed Systems / 11 - 29 4.1 Log for Banking Service

30. © Chinese University, CSE Dept. Distributed Systems / 11 - 30 4.1 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.

31. © Chinese University, CSE Dept. Distributed Systems / 11 - 31 4.2 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.

32. © Chinese University, CSE Dept. Distributed Systems / 11 - 32 4.2 Shadow Versions Example

33. © Chinese University, CSE Dept. Distributed Systems / 11 - 33 4.2 Log and 2PC

34. © Chinese University, CSE Dept. Distributed Systems / 11 - 34 4.3 Recovery of 2PC

35. © Chinese University, CSE Dept. Distributed Systems / 11 - 35 5 CORBA Transaction Service Application Objects CORBA facilities CORBA services Object Request Broker Transaction

36. © Chinese University, CSE Dept. Distributed Systems / 11 - 36 5 IDL Interfaces Object Transaction Service defined through three IDL interfaces:  Current  Coordinator  Resource

37. © Chinese University, CSE Dept. Distributed Systems / 11 - 37 5 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); };

38. © Chinese University, CSE Dept. Distributed Systems / 11 - 38 5 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);... };

39. © Chinese University, CSE Dept. Distributed Systems / 11 - 39 5 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(); };

40. © Chinese University, CSE Dept. Distributed Systems / 11 - 40 5 Transaction Example: Funds Transfer Acc1@bankA (Resource) Acc2@bankB (Resource) CurrentCoordinator begin() debit() get_control() credit() commit() prepare() register_resource() get_control() register_resource() prepare() commit()

41. © Chinese University, CSE Dept. Distributed Systems / 11 - 41 5 Summary  Transaction concepts: –ACID –Transaction commands –Roles of distributed components in transactions  Two-phase commit –phase one: voting –phase two: completion  Transaction recovery  CORBA Transaction Service –implements two-phase commit –needs resources that are transaction aware.