Distributed Systems
Topic 11: Transactions
Dr. Michael R. Lyu
Computer Science & Engineering Department
The Chinese University of Hong Kong
© Chinese University, CSE Dept.
Distributed Systems / 11 - 1
Outline
1 Motivation
2 Transaction Concepts
3 Two phase Commit
4 Transaction Recovery
5 CORBA Transaction Service
6 Summary
© Chinese University, CSE Dept.
Distributed Systems / 11 - 2
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?
© Chinese University, CSE Dept.
Distributed Systems / 11 - 3
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
© Chinese University, CSE Dept.
Distributed Systems / 11 - 4
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 5
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 6
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 7
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 8
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 9
2.3 Roles of Components
Distributed system components involved in
transactions can take role of:
Transactional Client
Transactional Server
Coordinator
© Chinese University, CSE Dept.
Distributed Systems / 11 - 10
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 11
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).
© Chinese University, CSE Dept.
Distributed Systems / 11 - 12
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 13
2.4 Flat Transactions
Begin
Trans.
Commit
Flat Transaction
Begin
Trans.
Crash
Flat Transaction
Rollbac
k
© Chinese University, CSE Dept.
Begin
Trans.
Abort
Flat Transaction
Rollbac
k
Distributed Systems / 11 - 14
2.4 Nested Transactions
Begin
Trans.
Commit
Main Transaction
Call
Call
Begin
Trans.
Commit
Begin
Trans.
Commit
Call
Begin
Trans.
Commit
© Chinese University, CSE Dept.
Distributed Systems / 11 - 15
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 16
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 17
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 18
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 19
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 20
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 21
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 22
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 23
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 24
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)
© Chinese University, CSE Dept.
Distributed Systems / 11 - 25
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 26
4 Entries in Recovery File
Type of entry
Description of contents of entry
Object
Transaction status
A value of an object
Transaction identifier, transaction status
(prepared, committed, aborted) and other
status values used for two-phase commit
Intentions list
Transaction identifier and a sequence of
intentions, each of which consists of <id of
object>, <position in recovery file of
value of object>
© Chinese University, CSE Dept.
Distributed Systems / 11 - 27
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 28
4.1 Log for Banking Service
© Chinese University, CSE Dept.
Distributed Systems / 11 - 29
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 30
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 31
4.2 Shadow Versions Example
© Chinese University, CSE Dept.
Distributed Systems / 11 - 32
4.2 Log and 2PC
© Chinese University, CSE Dept.
Distributed Systems / 11 - 33
4.3 Recovery of 2PC
© Chinese University, CSE Dept.
Distributed Systems / 11 - 34
5 CORBA Transaction Service
Application
Objects
CORBA
facilities
Object Request Broker
Transaction
© Chinese University, CSE Dept.
CORBA
services
Distributed Systems / 11 - 35
5 IDL Interfaces
Object Transaction Service defined through
three IDL interfaces:
Current
Coordinator
Resource
© Chinese University, CSE Dept.
Distributed Systems / 11 - 36
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);
};
© Chinese University, CSE Dept.
Distributed Systems / 11 - 37
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);
...
};
© Chinese University, CSE Dept.
Distributed Systems / 11 - 38
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();
};
© Chinese University, CSE Dept.
Distributed Systems / 11 - 39
5 Transaction Example: Funds Transfer
Acc1@bankA Acc2@bankB
(Resource)
begin() (Resource)
Current Coordinator
debit()
get_control()
credit()
register_resource()
get_control()
commit()
register_resource()
prepare()
prepare()
commit()
commit()
© Chinese University, CSE Dept.
Distributed Systems / 11 - 40
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.
© Chinese University, CSE Dept.
Distributed Systems / 11 - 41