Scribd
Upload
8 views15 pages

Unit - Iv

Uploaded by

prasannakumarsaras
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
8 views15 pages

Unit - Iv

Uploaded by

prasannakumarsaras
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

UNIT - IV

Coordination: Clock Synchronization - Logical clocks Fault Tolerance: Introduction to fault tolerance - Concepts
- Mutual Exclusion: Centralized algorithm - - Failure models - Failure masking by redundancy - Reliable
Distributed Algorithm - Token-ring algorithm - client server communication: Point to point
Decentralized Algorithm - Election Algorithms: Bully communication - RPC semantics in the presence of failures
algorithm - Ring algorithm - Elections in wireless - Reliable Group Communication: Atomic multicast,
environment and large scale systems Virtual synchrony and message ordering
Distributed commit
Recovery
Distributed Commit
• General Goal:
• We want an operation to be performed by all group
members, or none at all.
• [In the case of atomic multicasting, the operation is the
delivery of the message.]
There are three types of “commit protocol”:
1. single-phase commit
2. two-phase commit
3. three-phase commit

2
One-Phase Commit Protocol:
• An elected coordinator tells all the other processes to
perform the operation in question.

• But, what if a process cannot perform the operation?


There’s no way to tell the coordinator! Whoops …

• The solutions:
The Two-Phase and Three-Phase Commit Protocols.

3
The Two-Phase Commit Protocol
First developed in 1978!!!
Summarized: GET READY, OK, GO AHEAD.
1. The coordinator sends a VOTE_REQUEST message to all group
members.
2. The group member returns VOTE_COMMIT if it can commit
locally, otherwise VOTE_ABORT.
3. All votes are collected by the coordinator. A
GLOBAL_COMMIT is sent if all the group members voted to
commit. If one group member voted to abort, a
GLOBAL_ABORT is sent.
4. The group members then COMMIT or ABORT based on the
last message received from the coordinator.
Two-Phase Commit (1)

(a) The finite state machine for the coordinator in 2PC.


(b) The finite state machine for a participant.
Two-Phase Commit (2)
Three states in which either a coordinator or participant is blocked waiting for an incoming
message
1. A participant may be waiting in its INIT state for a vote-request message from the coordinator
• If that message is not received after some time, the participant will simply decide to locally
abort the transaction, and thus send a vote-abort message to the coordinator
2. The coordinator can be blocked in state WAIT, waiting for the votes of each participant
• If not all votes have been collected after a certain period of time, the coordinator should
vote for an abort as well, and subsequently send global-abort to all participants
3. A participant can be blocked in state READY, waiting for the global vote as sent by the
coordinator
• If that message is not received within a given time, the participant cannot simply decide to
abort the transaction. Instead, it must find out which message the coordinator actually
sent.
• The simplest solution to this problem is to let each participant block until the coordinator recovers again
• A better solution is to let a participant P contact another participant Q to see if it can decide from Q’s
current state what it should do
Two-Phase Commit (3)

Actions taken by a participant P when residing in state READY


and having contacted another participant Q
Two-Phase Commit (4)

...

Outline of the steps taken by the


coordinator in a two-phase commit protocol
Two-Phase Commit (5)

...

Outline of the steps taken by the


coordinator in a two-phase commit protocol
Two-Phase Commit (6)

(a) The steps taken by a participant process in 2PC


Two-Phase Commit (7)

(b) The steps for handling incoming decision requests


Big Problem with Two-Phase Commit
• It can lead to both the coordinator and the group members blocking,
which may lead to deadlock.
• If the coordinator crashes, the group members may not be able to
reach a final decision, and they may, therefore, block until the
coordinator recovers …
• Two-Phase Commit is known as a blocking-commit protocol for this
reason.
• Solution:
• Use a multicast primitive by which a receiver immediately
multicasts a received message to all other processes
• Use three phase
Three-Phase Commit (1)
The states of the coordinator and each participant satisfy the following two
conditions:
1. There is no single state from which it is possible to make a transition
directly to either a COMMIT or an ABORT state.
2. There is no state in which it is not possible to make a final decision, and
from which a transition to a COMMIT state can be made.
Three-Phase Commit (2)

(a) The finite state machine for the coordinator in 3PC.


(b) The finite state machine for a participant.
Three-Phase Commit (3)
• Participant in INIT state for vote request– aborts
• Coordinator in WAIT state for vote – aborts
• Coordinator blocked in PRECOMMIT state
• instructs the operational participants to commit by multicasting a global-commit
message
• In addition, it relies on a recovery protocol for the crashed participant to commit its
part of the transaction when it comes up again
• Participant P blocked in READY OR PRECOMMIT
• Q COMMIT -> P COMMIT
• Q ABORT -> P ABORT
• Q PRECOMMIT -> P COMMIT
• Q INIT -> P ABORT
• ALL Q IN READY -> P ABORT (Some Q crashed and may resume to INIT, ABORT OR
PRECOMMIT)
• A participant can reach PRECOMMIT only if the coordinator had reached state PRECOMMIT before crashing,
and has thus received a vote to commit from each participant

You might also like