Distributed Systems

1
Distributed Systems

• Topic 11 Transactions
• Dr. Michael R. Lyu
• Computer Science Engineering Department
• The Chinese University of Hong Kong

2
Outline

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

3
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?

4
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

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

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

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

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

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

10
2.3 Roles of Components

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

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

12
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).

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

14
2.4 Flat Transactions
15
2.4 Nested Transactions
16
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.

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

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

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

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

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

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

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

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

25
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 servers data items after a crash
• reorganize the recovery file for better
  performance
• reclaim storage space (in the recovery file)

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

27
4 Entries in Recovery File

• Type of entry Description of contents of entry
• Object A value of an object
• Transaction status 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 ltid of objectgt, ltposition in
  recovery file of value of objectgt

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

29
4.1 Log for Banking Service
30
4.1 Recovery by Logging

• Recovery of data items
• Recovery manager is responsible for restoring the
  servers 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.

31
4.2 Shadow Versions

• Shadow versions technique uses a map to locate
  versions of the servers 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.

32
4.2 Shadow Versions Example
33
4.2 Log and 2PC
34
4.3 Recovery of 2PC
35
5 CORBA Transaction Service
36
5 IDL Interfaces

• Object Transaction Service defined through three
  IDL interfaces
• Current
• Coordinator
• Resource

37
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)

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

39
5 Resource

• interface Resource
• Vote prepare()
• void rollback() raises(...)
• void commit() raises(...)
• void commit_one_phase raises(...)
• void forget()
• interface SubtransactionAwareResourceResource
• void commit_subtransaction(in Coordinator p)
• void rollback_subtransaction()

40
5 Transaction Example Funds Transfer
41
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.