--%>
Assignment Help - homework help

  Two phase commit protocol problem

Two phase commit protocol problem:

As described there is no solution to the two generals problem.

If nevertheless the restriction that the protocol have a few finite fixed maximum length is relaxed then a solution is possible. The protocol about to be described may perhaps require arbitrarily many messages. Generally it requires only a few messages sometimes it requires more and in some cases (a set of measure zero) it needs an infinite number of messages. The protocol works by initiating a commit coordinator. The commit coordinator has a communication path to each participant. Participants are either cohorts (processes) at numerous nodes or are autonomous components within a process (like DB and DC)or are both.

The commit coordinator asks each participant to go into a state such that no matter what happens the participant can either redo or else undo the transaction (this means writing the log in an extremely safe place).

Once the coordinator acquires the votes from everyone:

a) If anyone terminated the coordinator broadcasts abort to all participants records abort in his log and terminates. In this case each participant will abort.

b) If each participant voted yes the coordinator synchronously records a commit record in the log, afterwards broadcasts commit to all participants and when an acknowledge, is received from every participant the coordinator terminates.

The key to the accomplishment of this approach is that the decision to commit has been centralized in a single place and is not time constrained.

The following diagrams demonstrate the possible interactions among a coordinator and a participant. Note that a coordinator may perhaps abort a participant that agrees to commit. This may happen for the reason that another participant has aborted:

2385_commit protocol.jpg

Three possible two-phase commit scenarios.

The logic for the coordinator is best explained by a simple program:

COORDINATOR: PROCEDURE;
VOTE='COMMIT';                                 /*collect votes */
DO FOR EACH PARTICIPANT WHILE(VOTE='COMMIT');
DO;
SEND HIM REQUEST_COMMIT;
IF REPLY != 'AGREE' THEN VOTE='ABORT';
END;
IF VOTE='COMMIT' THEN
DO; /*if all agree then commit+/
WRITE_LOG(PHASE12_COMMIT)FORCE;
FOR EACH PARTICIPANT;
DO UNTIL (+ACK);
SEND HIM COMMIT;
WAIT +ACKNOWLEDGE;
IF TIME LIMIT THEN RETRANSMIT;
END;
END;
ELSE
DO; /*if any abort, then abort*/
FOR EACH PARTICIPANT
DO UNTIL (+ACK);
SEND MESSAGE ABORT;
WAIT +ACKNOWLEDGE;
IF TIME_LIMIT THEN RETRANSMIT;
END
END;
WRITE_LOG(COORDINATOR_COMPLETE);/*common exit*/
RETURN;
END COORDINATOR;

The protocol for the participant is simpler:

PARTICIPANT: PROCEDURE;
WAIT FOR REQUEST_COMMIT; /*phase 1 */
FORCE UNDO REDO LOG TO NONVOLATILE STORE;
IF SUCCESS THEN /*writes AGREE in log */
REPLY 'AGREE';
ELSE
REPLY 'ABORT';
WAIT FOR VERDICT; /*phase2 */
IF VERDICT ='COMMIT' THEN
DO;
RELEASE RESOURCES & LOCKS;
REPLY +ACKNOWLEDGE;
END;
ELSE
DO;
UNDO PARTICIPANT;
REPLY +ACKNOWLEDGE;
END;
END PARTICIPANT;

There is a last Piece of logic that requires being included- In the event of restart recovery manager has merely the log and the non-volatile store. If the coordinator crashed prior to the PHASE12_COMMIT record appeared in the log then restart will broadcast abort to all participants. If the transaction's PHASE12_COMMIT record appeared as well as the COORDINATOR_COMPLETE record didn’t appear then restart will re-broadcast the COMMIT message. If the transaction's COORDINATOR_COMPLETE record appears in the log afterwards restart will ignore the transaction. Likewise transactions will be aborted if the log has not been forced with AGREE. If the AGREE record appears afterwards restart asks the coordinator whether the transaction committed or else aborted and acts accordingly (redo or undo.)

Examination of this protocol illustrates that transaction commit has two phases:

1. Prior to its PHASE12_COMMIT or AGREE_COMMIT log record has been written and
2. Subsequent to its PHASE12_COMMIT or AGREE_COMMIT log record has been written.

This is the reason it is called a two-phase commit protocol. A moderately lengthy analysis is required to convince oneself that a crash or lost message will not cause one participant to “march" the wrong way.

Let us consider a few cases. If any participant aborts or else crashes in his phase 1 then the whole transaction will be aborted (because the coordinator will sense that he isn’t replying using timeout).

If a participant crashes in his phase 2 afterwards recovery manager as a part of restart of that participant, will ask the coordinator whether or not to redo or else undo the transaction instance. Since the participant wrote sufficient information for this in the log during phase 1, recovery manager is able to go either way on completing this participant. This requires that the undo as well as redo be idempotent operations. On the other hand if the coordinator crashes before it writes the log record then restart will broadcast abort to all participants. No participant has committed for the reason that the coordinator’s PHASE12_COMMIT record is synchronously written prior to any commit messages are sent to participants. Alternatively if the coordinator's PHASE12_COMMIT record is found in the log at restart afterwards the recovery manager broadcasts commit to all participants and waits for acknowledge. This redo the transaction (coordinator).

This rather sloppy argument is able to be (has been) made more precise. The net result of the algorithm is that either all the participants commit or that none of them commit (all abort.)

Latest technology based Operating System Online Tutoring Assistance

Tutors, at the www.tutorsglobe.com, take pledge to provide full satisfaction and assurance in Operating System help via online tutoring. Students are getting 100% satisfaction by online tutors across the globe. Here you can get homework help for Operating System, project ideas and tutorials. We provide email based Operating System help. You can join us to ask queries 24x7 with live, experienced and qualified online tutors specialized in Operating System. Through Online Tutoring, you would be able to complete your homework or assignments at your home. Tutors at the TutorsGlobe are committed to provide the best quality online tutoring assistance for Operating System Homework help and assignment help services. They use their experience, as they have solved thousands of the Operating System assignments, which may help you to solve your complex issues of Operating System. TutorsGlobe assure for the best quality compliance to your homework. Compromise with quality is not in our dictionary. If we feel that we are not able to provide the homework help as per the deadline or given instruction by the student, we refund the money of the student without any delay.