我指的是https://en.wikipedia.org/wiki/Two-phase_commit_protocol处的两阶段提交说明。
在预提交阶段,假设两位资源经理都投了赞成票。
如果事务管理器通过向每个资源管理器发送COMMIT消息来启动提交,并且只有其中一个返回ACK,而另一个没有,那么事务管理器如何从第一个资源管理器回滚已提交的事务。成功提交?
当全局事务失败时,是否有可能在一个资源管理器上而不是另一个资源管理器上提交事务?
答案 0 :(得分:1)
是的,的确如此。
在这种情况下,事务协调器通知所有成功提交事务的各方必须将其回滚。
这应该是由硬件故障或磁盘用尽等问题引起的相对罕见的情况。在许多系统上,回滚涉及撤消从日志文件中读取的更改。
这一点也在您链接的文章中进行了解释。
答案 1 :(得分:0)
我想说这取决于您使用的事务协调器的实现以及commit
生成的错误类型。 (我熟悉Narayana交易经理。)
关于第一个问题 - 如果事务参与者提交,那么事务协调器没有任何通用方法如何撤消它。如果2PC中出现差异(某些参与者提交而其他参与者失败),则事务协调员会宣布启发式异常,并由管理员手动修复该事件。是的,也许您需要使用一些内部数据库日记以防万一。
但2PC谈论了两个阶段,第一阶段在这里是相关的。如果所有参与者从准备阶段返回OK,则表示所有参与者在其内部事务日志中创建记录。在DB的情况下,当准备事务并且某些行被锁定以更改其他事务时。 DB然后等待协调器驱动提交。如果DB没有得到提交命令,则等待 - 例如,如果从协调器到DB的连接中断,则等待连接再次启动。即使该事务协调器未能及时完成事务(当连接崩溃时)它将(可能)在连接再次启动时完成其工作。
现在取决于发生了什么故障。连接崩溃的示例被视为临时操作,事务协调器可以在建立连接后完成工作。如果存在严重问题,则参与者将有关它的信息返回给事务协调员,然后如上所述将其通知启发式异常。
就是这样 - 万一有一个参与者可以被提交而另一个被回滚,因为你的第二个问题就是这样。