|
|
|
.当一参与者在写入“建议提交”前发生故障时，该参与者无法向协调者发回答信息，因此，当协调者等待超时后，将决定终止事务。当该故障恢复后，该参与者无须收集其他场地的信息即可终止事务。
|
|
|
|
.参与者进程在写入“建议提交”后发生故障，这时其他的参与者可以正常结束该事务，“提交”或“撤销”，因为协调者可以根据收到该参与者的应答决定“提交”或“撤销”。因此，故障恢复后，该参与者要访问协调者或其他参与者，以了解协调者对事务做出的决定，然后执行相应的操作“提交”或“撤销”。这里我们假设在日志中写入“建议提交”记录和发送“建议提交”信息给协调者这两个动作具有原子性，要么都执行，要么都不执行。
|
|
|
|
.协调者在日志中写入“准备提交”记录后，写入“全局提交”或“全局撤销”前发生故障，这时已发出“建议提交”信息的参与者等待协调者恢复。协调者的重启动过程从头恢复提交协议，从“准备提交”记录中读出参与者的标识符，重发“准备提交”报文给参与者，重新执行提交过程。
|
|
|
|
.协调者在写入“全局提交”或“全局撤销”记录以后，在写入“事务结束”记录以前发生故障。在这种情况下，协调者恢复时必须给所有的参与者重发其决定，未收到信息的参与者不得不等待协调者的恢复。
|
|
|
