|
|
知识路径： > 数据库主流应用技术 > 数据库主流应用技术 > 数据库主流应用技术 > 分布式数据库 > 分布事务管理 >
|
|
相关知识点：14个
|
|
|
|
|
由于系统的故障，报文可能没有收到。与2PC一样，3PC也采用超时方法处理。
|
|
|
|
第一种情况是协调者没能及时发出“准备提交”报文，导致参与者等待超时，这时参与者决定撤销。
|
|
|
|
第二种情况是协调者等待参与者投票结果超时，这时协调者决定撤销。
|
|
|
|
第三种情况是参与者处于“赞成”提交状态，等待“全局预提交”命令时出现超时，这时进入恢复处理过程。
|
|
|
|
第四种情况是参与者处于“准备就绪”状态等待协调者的“全局提交”命令出现超时，也进入恢复处理，这时只要有至少一个参与者处于活动状态，子事务就不会阻塞。因为恢复后的参与者可以从活动子事务得到有关提交处理的信息，从而得知协调者的决定，依据协调者的决定确定自己应做的处理。
|
|
|
|
|
|
（1）一个参与者在其他任何一个活动的参与者处于赞成提交状态时，不可能进入“提交”状态。
|
|
|
|
（2）一个参与者在另一个参与者进入提交状态或任何一个参与者都进入准备就绪状态时不能进入撤销状态。
|
|
|
|
因此，恢复时参与者可以根据活动事务的状态决定相应的处理。在3PC协议中，恢复机制唯一可以做的是就近访问一个活动的参与者，确切地说是访问在它进入恢复处理前最近的活动参与者。如果所有的参与者处于“赞成”提交或“撤销”状态，则肯定没有一个参与者已提交，因此可以通知全部参与者“撤销”。如果已经有一个参与者“准备就绪”或“提交”，则肯定没有一个参与者被“撤销”，所以可以通知全部参与者提交，在通知“全局提交”前应先将仍处于“赞成”提交的参与者进入“准备提交”状态，然后再进入“提交”状态。因为在通知提交前，任何一个参与者均可能再发生故障，所以应避免其中一个参与者处于“赞成”提交状态而另一个处于“提交”状态。
|
|
|
