|
|
知识路径： > 数据库主流应用技术 > 数据库主流应用技术 > 数据库主流应用技术 > 分布式数据库 > 分布事务管理 >
|
|
相关知识点：11个
|
|
|
|
|
|
|
.当一参与者在写入“建议提交”前发生故障时，该参与者无法向协调者发回答信息，因此，当协调者等待超时后，将决定终止事务。当该故障恢复后，该参与者无须收集其他场地的信息即可终止事务。
|
|
|
|
.参与者进程在写入“建议提交”后发生故障，这时其他的参与者可以正常结束该事务，“提交”或“撤销”，因为协调者可以根据收到该参与者的应答决定“提交”或“撤销”。因此，故障恢复后，该参与者要访问协调者或其他参与者，以了解协调者对事务做出的决定，然后执行相应的操作“提交”或“撤销”。这里我们假设在日志中写入“建议提交”记录和发送“建议提交”信息给协调者这两个动作具有原子性，要么都执行，要么都不执行。
|
|
|
|
.协调者在日志中写入“准备提交”记录后，写入“全局提交”或“全局撤销”前发生故障，这时已发出“建议提交”信息的参与者等待协调者恢复。协调者的重启动过程从头恢复提交协议，从“准备提交”记录中读出参与者的标识符，重发“准备提交”报文给参与者，重新执行提交过程。
|
|
|
|
.协调者在写入“全局提交”或“全局撤销”记录以后，在写入“事务结束”记录以前发生故障。在这种情况下，协调者恢复时必须给所有的参与者重发其决定，未收到信息的参与者不得不等待协调者的恢复。
|
|
|
|
|
|
.至少有一个参与者的回答报文（“建议提交”或“建议撤销”）丢失了。在这种情况下，协调者将等待回答而超时，整个事务被撤销。这种情况只由协调者发现，但它无法决定是场地故障还是通信故障，而参与者能够正确执行，它不会启动恢复过程。
|
|
|
|
.丢失“准备提交”报文，由于至少有一个参与者收不到“准备提交”命令，因此参与者处于等待状态，而协调者也等待参与者的回答，所以协调者会因为等待超时而撤销事务。这种情况和上述一样。
|
|
|
|
.丢失“全局提交”或“全局撤销”报文，这种情况下参与者处于等待协调者命令的状态下，当参与者未收到命令时，会因等待而超时，这时向协调者请求重发该命令的信息。
|
|
|
|
.丢失了“确认”报文，当协调者未收到全部参与者的“确认”报文时，协调者会因等待而超时，这时协调者重发命令报文给参与者，这时参与者必须给予“确认”报文回答，即使此时相应的子事务已不在活动也要重发。
|
|
|
|
|
|
假设在出现网络分割时，整个网被分为两个组，包含协调者的组称为协调者组，其他的则组成参与者组。这种情况对于协调者来说相当于参与者组中的多个参与者同时发生故障，这时协调者可以做出决定，然后把命令发给协调者组中的参与者，因此这些场地上的子事务可以结束。而对于失去联系的参与者，它们则认为协调者出现故障，根据它们所缺少的回答信息，进行相应的故障处理。
|
|
|
