A.Failure Handling in 2PC

We now examine in detail how 2PC responds to various types of failures. As we shall see, one major disadvantage of the 2PC protocol is that coordinator failire may result in blocking, where a decision either to commit or to abort T may have to be postponed untul Ci recovers.

1.Failure of a Participating Site
When a participating site Sk recovers from a failure, it must examine its log to determine the fate of those transactions that were in the midst of execution when the failure occureed. Let T be one suck transaction. We consider each of the possible cases:
The log contains a record. In this case, the site executes redo(T).
The log contains an . in this In this case, the site executes undo(T).
The log contains a record. In this case, the site must consult Ci to determine the fate of T. if Ci is up, it notifies Sk regarding whether T committed or aborted. In the former case, it executes redo(T):in the latter case, it executes undo(T). if Ci is down, Sk must try to find the fate of T from other sites. It does so by sending a query-status T massage to all the sites in the system. On receiving such a message, a site must consult its log to determine whether T has executed there, and if so, whether T committed or aborted. It then notifies Sk about this outcome. It no site has the apporopriate information (that is, whether T committed or aborted), then Sk can neither abort nor commit T. The decision concerting T is postponod until Sk can obtain the needed information. Thus, Sk must periodically resend the query-status mwssage to the other sites. It does so until a site recovers that contains the needed information. Note that the site at which Ci resides always has the needed information.
The log contains no control records (abort, commit, ready) concerning T. Theabsence of control records implies that Sk failed before responding to the prepare T message from Ci. Since the failure of Sk precludes the sending of suck a response, by our olgorithm Ci must abotrt T. hence, Sk must execute undo(T).

2.Failure of the Coordinator
If the coordinator fails in the midst of the execution of the commit protocol for transaction T, then the participating sites must decide on the fate of T. we shall see that, in certain cases, the participating sites cannot decide whether to commit or abort T, and therefore it is necessary for these sites to wait for the recovery of the failed coordinator.
If an active site contains a record in its log, then T must be committed.
If an active site contains a record in its log, then T must be aborted.
If some active site does not contain a record in its log, then the failed coordinator Ci cannot have decided to commit T. We can draw this conclusion because a site that does not have a record in its log cannot have sent a ready T message to Ci. However, the coordinator may have decided to abort T, but not to commit T. Rather that wait for Ci to recover, it is preferable to abort T.
If none of the preceding cases holds, then all active sites must have a record in their logs, but no additional control (such as or ). Since the coordinator has failed, it is impossible to determine whether a decision has been made, or what that decision is, until the coordinator recovers. Thuis, the active sites must wait for Ci to recover. Since the fate of T remain in doubt, T may continue to hold system resource. For exemple, if locking is used, T may hold lock on data at active sites. Suck a situation is undesirable because it may take hours or days before Ci is again active. During this time other transaction may be forced to nwait for T. as a result, data are unavailable not only on the failed site (Ci) but on active sites as well. Tne number of unavailable data increase as he downtime of Ci grows. This situation is called the blocking problem, because T is blocked pending the recovery of site Ci.]

3.Failure of the Network
When alink fails, all the messages that are in the process of being routed through the link do not arrive at their destination intact. From the viewpoint of the sites connected throughout that link, it appears that the other sites have failed. Thus, our previous schemes apply here as well.
When a number of links fail, the network may partition. In this case, two possibilities exist. The coordinator and all its participant may remain in one partition: in this case, the failure has on effect on the commit protocol. Alternatively, the coordinator and its participants may belong to several partitions:in this case, message between the participant and the coordinator are lost, reducing the case a link failure, as discussed.