1. © City University London, Dept. of Computing Distributed Systems / 9 - 1 Distributed Systems Session 9: Transactions Christos Kloukinas Dept. of Computing City University London

2. © City University London, Dept. of Computing Distributed Systems / 9 - 2 Last Session: Summary  Lost updates and inconsistent analysis.  Pessimistic vs. optimistic concurrency control »Pessimistic control: –higher overhead for locking. +works efficiently in cases where conflicts are likely »Optimistic control: +small overhead when conflicts are unlikely. –distributed computation of conflict sets expensive. –requires global clock.  CORBA uses pessimistic two-phase locking.

3. © City University London, Dept. of Computing Distributed Systems / 9 - 3 Session 9 - Outline 1 Motivation 2 Transaction Concepts 3 Two phase Commit 4 CORBA Transaction Service 5 Summary

4. © City University London, Dept. of Computing Distributed Systems / 9 - 4 1 Motivation  What happens if a failure occurs during modification of resources? »e.g. system failure, disk crash  Which operations have been completed? »e.g in cash transfer scenario; was debit successful?  Which operations have not (and have to be done again)? »was credit unsuccessful??  In which states will the resources be? »e.g. Has the money being lost on its way and does it need to be recovered?

5. © City University London, Dept. of Computing Distributed Systems / 9 - 5 What is Required? Transactions  Clusters a sequence of object requests together such that they are performed with ACID properties »i.e transaction is either performed completely or not at all »leads from one consistent state to another »is executed in isolation from other transactions »once completed it is durable  Used in Databases and Distributed Systems  For example consider the Bank account scenario from last session

6. © City University London, Dept. of Computing Distributed Systems / 9 - 6 Scenario Class Diagram DirectBanking + funds_transfer(from:Account, to:Account,amount:float) InlandRevenue + sum_of_accounts( set:Account[]):float Account -balance:float =0 + credit(amount:float) +debit(amount:float) +get_balance():float A funds transfer involving a debit operation from one account and a credit operation from another account would be regarded as a transaction Both operations will have to be executed or not at all. They should be isolated from other transactions. They should be durable, once transaction is completed. They leave the system in a consistent state.

7. © City University London, Dept. of Computing Distributed Systems / 9 - 7 2 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

8. © City University London, Dept. of Computing Distributed Systems / 9 - 8 2.1.1 Atomicity  Transactions are either performed completely or no modification is done. »I.e perform successfully every operation in cluster or none is performed »e.g. both debit and credit in the scenario  Start of a transaction is a continuation point to which it can roll back.  End of transaction is next continuation point.

9. © City University London, Dept. of Computing Distributed Systems / 9 - 9 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. »e.g for our scenario, consistency means “no money is lost”: at the end this is true, but in between operations it may be not  Transactions can be aborted if they cannot resolve inconsistencies.

10. © City University London, Dept. of Computing Distributed Systems / 9 - 10 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.

11. © City University London, Dept. of Computing Distributed Systems / 9 - 11 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 EEPROMs.

12. © City University London, Dept. of Computing Distributed Systems / 9 - 12 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.

13. © City University London, Dept. of Computing Distributed Systems / 9 - 13

14. © City University London, Dept. of Computing Distributed Systems / 9 - 14 2.3 Roles of Components Distributed system components involved in transactions can take role of:  Transactional Client  Transactional Server  Coordinator

15. © City University London, Dept. of Computing Distributed Systems / 9 - 15 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.

16. © City University London, Dept. of Computing Distributed Systems / 9 - 16 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).

17. © City University London, Dept. of Computing Distributed Systems / 9 - 17 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.

18. © City University London, Dept. of Computing Distributed Systems / 9 - 18 2.4 Flat Transactions Flat Transaction Commit Crash Flat Transaction Rollbac k Begin Trans. Begin Trans. Rollbac k Begin Trans. Flat Transaction Abort

19. © City University London, Dept. of Computing Distributed Systems / 9 - 19 3 Two-Phase Commit  Committing a distributed transaction involves distributed decision making.Communication defines commit protocol  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, then every server has to abort.  Single phase protocol is insufficient.  Two phases are needed: »Phase one: Voting »Phase two: Completion.

20. © City University London, Dept. of Computing Distributed Systems / 9 - 20 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 know yet 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. © City University London, Dept. of Computing Distributed Systems / 9 - 21 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.

22. © City University London, Dept. of Computing Distributed Systems / 9 - 22 Object Request for 2 Phase Commit Acc1@BankA :Resource Acc2@BankB :Resource :Coordinator begin() debit()register_resource() credit() commit() register_resource() vote() doCommit()

23. © City University London, Dept. of Computing Distributed Systems / 9 - 23 3 Server Uncertainty (1)  Period when a server is able to commit, but does not yet know if it has to..  This period is known as server uncertainty.  Usually short (time needed for co-ordinator to receive and process votes).  However, failures can lengthen this process, which may cause problems.  Solution is to store changes of transaction in temporary persistent storage e.g. log file, and use for recovery on restarting.

24. © City University London, Dept. of Computing Distributed Systems / 9 - 24 3 Recovery in Two-Phase Commit  Failures prior to the start of 2PC result in abort.  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.

25. © City University London, Dept. of Computing Distributed Systems / 9 - 25 3 Recovery in Two-Phase Commit  Coordinator failure prior to transmitting DoCommit messages results in abort (since no server has already committed).  After this point, co-ordinator will retransmit all DoCommit messages on restart. »This is why servers have to store even their provisional changes in a persistent way. »The coordinator itself needs to store the set of participating servers in a persistent way too.

26. © City University London, Dept. of Computing Distributed Systems / 9 - 26 4 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()

27. © City University London, Dept. of Computing Distributed Systems / 9 - 27 5 Summary  Transaction concepts: »ACID »Transaction commands (begin, (vote), commit, abort) »Roles of distributed components in transactions  Two-phase commit »phase one: voting »phase two: completion  CORBA Transaction Service »implements two-phase commit »needs resources that are transaction aware.

28. © City University London, Dept. of Computing Distributed Systems / 9 - 28 4 CORBA Transaction Service Application Objects CORBA facilities CORBA services Object Request Broker Transaction

29. © City University London, Dept. of Computing Distributed Systems / 9 - 29 4 IDL Interfaces Object Transaction Service defined through three IDL interfaces:  Current (transaction interface)  Coordinator  Resource (transactional servers)

30. © City University London, Dept. of Computing Distributed Systems / 9 - 30 4 Current – Implicit Current Tx 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); }; (every CORBA object has an implicit transaction associated with it)

31. © City University London, Dept. of Computing Distributed Systems / 9 - 31 4 Coordinator – Explicit Tx 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);... };

32. © City University London, Dept. of Computing Distributed Systems / 9 - 32 4 Resource interface Resource { Vote prepare(); // ask the resource/server to vote 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(); };