Distributed Systems Session 9 Transactions Christos Kloukinas Dept

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

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

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

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

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

Scenario Class Diagram Direct. Banking +funds_transfer(from: Account, to: Account, amount: float) Account -balance: float =0 +credit(amount: float) Inland. Revenue +debit(amount: float) +get_balance(): float +sum_of_accounts( set: Account[]): 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 leave the system in a consistent state. • They should be isolated from other transactions. • They should be durable, once transaction is completed. © City University London, Dept. of Computing Distributed Systems / 9 - 6

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

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. © City University London, Dept. of Computing Distributed Systems / 9 - 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. » 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. © City University London, Dept. of Computing Distributed Systems / 9 - 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. © City University London, Dept. of Computing Distributed Systems / 9 - 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. ¨ May not just be disk but can include properly battery-backed RAM or the like of EEPROMs. © City University London, Dept. of Computing Distributed Systems / 9 - 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. © City University London, Dept. of Computing Distributed Systems / 9 - 12

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

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

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

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

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

2. 4 Flat Transactions Begin Trans. Commit Flat Transaction Begin Trans. Crash Flat Transaction Rollback © City University London, Dept. of Computing Begin Trans. Abort Flat Transaction Rollback Distributed Systems / 9 - 18

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

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

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 » ‘Do. Commit’ if transaction is to be committed. » Otherwise ‘Abort'. ¨ Servers acknowledge Do. Commit once they have committed. © City University London, Dept. of Computing Distributed Systems / 9 - 21

Object Request for 2 Phase Commit begin() debit() Acc 1@Bank. A : Resource Acc 2@Bank. B : Resource : Coordinator register_resource() credit() register_resource() commit() vote() do. Commit() © City University London, Dept. of Computing Distributed Systems / 9 - 22

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

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

3 Recovery in Two-Phase Commit ¨ Coordinator failure prior to transmitting Do. Commit messages results in abort (since no server has already committed). ¨ After this point, co-ordinator will retransmit all Do. Commit 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. © City University London, Dept. of Computing Distributed Systems / 9 - 25

4 Transaction Example: Funds Transfer Acc 1@bank. A Acc 2@bank. B (Resource) begin() (Resource) debit() credit() commit() Current Coordinator get_control() register_resource() prepare() commit() © City University London, Dept. of Computing Distributed Systems / 9 - 26

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

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

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

4 Current – Implicit Current Tx interface Current { void begin() raises (. . . ); void commit (in boolean report_heuristics) raises (No. Transaction, Heuristic. Mixed, Heuristic. Hazard); void rollback() raises(No. Transaction); Status get_status(); string get_transaction_name(); Coordinator get_control(); Coordinator suspend(); void resume(in Coordinator which) raises(Invalid. Control); }; (every CORBA object has an implicit transaction associated with it) © City University London, Dept. of Computing Distributed Systems / 9 - 30

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); Recovery. Coordinator register_resource( in Resource r) raises(Inactive); void register_subtran_aware( in subtransaction. Aware. Resource r) raises(Inactive, Not. Subtransaction); . . . }; © City University London, Dept. of Computing Distributed Systems / 9 - 31

4 Resource interface Resource { Vote prepare(); // ask the resource/server to vote void rollback() raises(. . . ); void commit_one_phase raises(. . . ); void forget(); }; interface Subtransaction. Aware. Resource: Resource { void commit_subtransaction(in Coordinator p); void rollback_subtransaction(); }; © City University London, Dept. of Computing Distributed Systems / 9 - 32