Chapter 19 Distributed Databases.ppt

Distributed Transactions and 2 Phase Commit Handling of Failures- Coordinator Failure If coordinator fails while the commit protocol for T is executing then participating sites must decide on T’s fate: If an active site contains a commit T record in its log, then T must be committed. If an active site contains an abort T record in its log, then T must be aborted. If some active participating site does not contain a ready T record in its log, then the failed coordinator Ci cannot have decided to commit T. Can therefore abort T; however, such a site must reject any subsequent prepare T message from Ci If none of the above cases holds, then all active sites must have a ready T record in their logs, but no additional control records (such as abort T of commit T). In this case active sites must wait for Ci to recover, to find decision. Blocking problem: active sites may have to wait for failed coordinator to recover. Implementation of Persistent Messaging Sending site protocol. When a transaction wishes to send a persistent message, it writes a record containing the message in a special relation messages_to_send; the message is given a unique message identifier. A message delivery process monitors the relation, and when a new message is found, it sends the message to its destination. The message delivery process deletes a message from the relation only after it receives an acknowledgment from the destination site. If it receives no acknowledgement from the destination site, after some time it sends the message again. It repeats this until an acknowledgment is received. If after some period of time, that the message is undeliverable, exception handling code provided by the application is invoked to deal with the failure. Writing the message to a relation and processing it only after the transaction commits ensures that the message will be delivered if and only if the transaction commits. Implementation of Persistent Messaging (Cont.) Receiving site protocol. W