Phase 1:Obtaining a Decision Coordinator asks all participants to prepare to commit transaction Ti. Ci adds the records <prepare 7>to the log and forces log to stable storage sends prepare T messages to all sites at which T executed Upon receiving message,transaction manager at site determines if it can commit the transaction if not,add a record <no T>to the log and send abort T message to Ci if the transaction can be committed,then: add the record <ready T>to the log force all records for T to stable storage send ready T message to C Database System Concepts-6th Edition 19.22 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.22 ©Silberschatz, Korth and Sudarshan th Edition Phase 1: Obtaining a Decision Coordinator asks all participants to prepare to commit transaction Ti . Ci adds the records <prepare T> to the log and forces log to stable storage sends prepare T messages to all sites at which T executed Upon receiving message, transaction manager at site determines if it can commit the transaction if not, add a record <no T> to the log and send abort T message to Ci if the transaction can be committed, then: add the record <ready T> to the log force all records for T to stable storage send ready T message to Ci
Phase 2:Recording the Decision T can be committed of C;received a ready T message from all the participating sites:otherwise Tmust be aborted. Coordinator adds a decision record,<commit T>or <abort T>,to the log and forces record onto stable storage.Once the record stable storage it is irrevocable (even if failures occur) Coordinator sends a message to each participant informing it of the decision (commit or abort) Participants take appropriate action locally. Database System Concepts-6th Edition 19.23 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.23 ©Silberschatz, Korth and Sudarshan th Edition Phase 2: Recording the Decision T can be committed of Ci received a ready T message from all the participating sites: otherwise T must be aborted. Coordinator adds a decision record, <commit T> or <abort T>, to the log and forces record onto stable storage. Once the record stable storage it is irrevocable (even if failures occur) Coordinator sends a message to each participant informing it of the decision (commit or abort) Participants take appropriate action locally
Handling of Failures -Site Failure When site S;recovers,it examines its log to determine the fate of transactions active at the time of the failure. Log contain <commit T>record:txn had completed,nothing to be done Log contains <abort T>record:txn had completed,nothing to be done Log contains <ready T>record:site must consult C;to determine the fate of 7. If T committed,redo (D);write <commit T>record If T aborted,undo(刀 The log contains no log records concerning T: Implies that Sk failed before responding to the prepare T message from Ci since the failure of Sk precludes the sending of such a response, coordinator C must abort T Skmust execute undo(刀 Database System Concepts-6th Edition 19.24 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.24 ©Silberschatz, Korth and Sudarshan th Edition Handling of Failures - Site Failure When site Si recovers, it examines its log to determine the fate of transactions active at the time of the failure. Log contain <commit T> record: txn had completed, nothing to be done Log contains <abort T> record: txn had completed, nothing to be done Log contains <ready T> record: site must consult Ci to determine the fate of T. If T committed, redo (T); write <commit T> record If T aborted, undo (T) The log contains no log records concerning T: Implies that Sk failed before responding to the prepare T message from Ci since the failure of Sk precludes the sending of such a response, coordinator C1 must abort T Sk must execute undo (T)
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: 1.If an active site contains a <commit T>record in its log,then T must be committed. 2.If an active site contains an <abort T>record in its log,then T must be aborted. 3.If some active participating site does not contain a <ready T>record in its log,then the failed coordinator C cannot have decided to commit 7. Can therefore abort T;however,such a site must reject any subsequent <prepare T>message from C 4.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 C,to recover,to find decision. Blocking problem:active sites may have to wait for failed coordinator to recover. Database System Concepts-6th Edition 19.25 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.25 ©Silberschatz, Korth and Sudarshan th Edition 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: 1. If an active site contains a <commit T> record in its log, then T must be committed. 2. If an active site contains an <abort T> record in its log, then T must be aborted. 3. 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 4. 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
Handling of Failures -Network Partition If the coordinator and all its participants remain in one partition,the failure has no effect on the commit protocol. If the coordinator and its participants belong to several partitions: Sites that are not in the partition containing the coordinator think the coordinator has failed,and execute the protocol to deal with failure of the coordinator. No harm results,but sites may still have to wait for decision from coordinator. The coordinator and the sites are in the same partition as the coordinator think that the sites in the other partition have failed,and follow the usual commit protocol. Again,no harm results Database System Concepts-6th Edition 19.26 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.26 ©Silberschatz, Korth and Sudarshan th Edition Handling of Failures - Network Partition If the coordinator and all its participants remain in one partition, the failure has no effect on the commit protocol. If the coordinator and its participants belong to several partitions: Sites that are not in the partition containing the coordinator think the coordinator has failed, and execute the protocol to deal with failure of the coordinator. No harm results, but sites may still have to wait for decision from coordinator. The coordinator and the sites are in the same partition as the coordinator think that the sites in the other partition have failed, and follow the usual commit protocol. Again, no harm results