© City University London, Dept. of Computing Distributed Systems / 9 - 1
Distributed Systems
Session 9: Transactions
Christos KloukinasDept. of Computing
City University London
© 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.
© 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
© 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?
© 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
© 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.
© 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
© 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.
© 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.
© 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.
© 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.
© 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.
© City University London, Dept. of Computing Distributed Systems / 9 - 13
© 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
© 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.
© 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).
© 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.
© City University London, Dept. of Computing Distributed Systems / 9 - 18
2.4 Flat Transactions
Flat Transaction
Commit
Crash
Flat Transaction
Rollback
BeginTrans.
BeginTrans.
Rollback
BeginTrans.
Flat Transaction
Abort
© 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.
© 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.
© 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.
© City University London, Dept. of Computing Distributed Systems / 9 - 22
Object Request for 2 Phase Commit
Acc1@BankA:Resource
Acc2@BankB:Resource
:Coordinatorbegin()
debit() register_resource()
credit()
commit()
register_resource()
vote()
vote()
doCommit()
doCommit()
© 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.
© 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.
© 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.
© City University London, Dept. of Computing Distributed Systems / 9 - 26
4 Transaction Example: Funds Transfer
Acc1@bankA(Resource)
Acc2@bankB(Resource) Current Coordinator
begin()
debit() get_control()
credit()
commit()
prepare()
register_resource()
get_control()
register_resource()
prepare()commit()commit()
© 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.
© City University London, Dept. of Computing Distributed Systems / 9 - 28
4 CORBA Transaction Service
ApplicationObjects
CORBAfacilities
CORBAservices
Object Request Broker
Transaction
© City University London, Dept. of Computing Distributed Systems / 9 - 29
4 IDL Interfaces
Object Transaction Service defined through three IDL interfaces:
Current (transaction interface)
CoordinatorResource (transactional servers)
© 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)
© 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); ...};
© 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();
};