Distributed Systems

1
Distributed Systems

• Session 9 Transactions
• Christos Kloukinas
• Dept. of Computing
• City University London

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
Session 9 - Outline

• 1 Motivation
• 2 Transaction Concepts
• 3 Two phase Commit
• 4 CORBA Transaction Service
• 5 Summary

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
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
Scenario Class Diagram

• 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.

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
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
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
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
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
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
(No Transcript)
14
2.3 Roles of Components

• Distributed system components involved in
  transactions can take role of
• Transactional Client
• Transactional Server
• Coordinator

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
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
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
2.4 Flat Transactions
Begin Trans.
Commit
Flat Transaction
Begin Trans.
Begin Trans.
Abort
Crash
Flat Transaction
Flat Transaction
Rollback
Rollback
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
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
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
Object Request for 2 Phase Commit
Acc1_at_BankA Resource
Acc2_at_BankB Resource
Coordinator
begin()
debit()
register_resource()
credit()
register_resource()
commit()
vote()
vote()
doCommit()
doCommit()
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
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
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
4 Transaction Example Funds Transfer
Acc1_at_bankA (Resource)
Acc2_at_bankB (Resource)
Current
Coordinator
begin()
debit()
get_control()
register_resource()
credit()
get_control()
register_resource()
commit()
prepare()
prepare()
commit()
commit()
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
4 CORBA Transaction Service
Application Objects
CORBAfacilities
Object Request Broker
CORBAservices
Transaction
29
4 IDL Interfaces

• Object Transaction Service defined through three
  IDL interfaces
• Current (transaction interface)
• Coordinator
• Resource (transactional servers)

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
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
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 SubtransactionAwareResourceResource
• void commit_subtransaction(in Coordinator p)
• void rollback_subtransaction()