我指的是https://en.wikipedia.org/wiki/Two-phase_commit_protocol上对两阶段提交的描述。
在预提交阶段,假设两个资源经理都投了赞成票。
如果事务管理器通过向每个资源管理器发送 COMMIT 消息来发起提交,并且其中只有一个返回 ACK,而另一个没有,事务管理器如何从第一个成功提交的资源管理器回滚已经提交的事务?
当全局事务失败时,是否有可能在一个资源管理器上而不是另一个资源管理器上提交事务?
我指的是https://en.wikipedia.org/wiki/Two-phase_commit_protocol上对两阶段提交的描述。
在预提交阶段,假设两个资源经理都投了赞成票。
如果事务管理器通过向每个资源管理器发送 COMMIT 消息来发起提交,并且其中只有一个返回 ACK,而另一个没有,事务管理器如何从第一个成功提交的资源管理器回滚已经提交的事务?
当全局事务失败时,是否有可能在一个资源管理器上而不是另一个资源管理器上提交事务?
Yes, indeed.
In that case the transaction coordinator informs all parties, which successfully committed the transaction, that they must roll it back.
This should usually be a relatively rare condition caused by problems like hardware faults or running out of disk place. On many systems, the roll back involves undoing changes read from a journal file.
This is all explained in the article you link to as well.
我会说这取决于您使用的事务协调器的实现以及commit
产生的错误类型。(我熟悉 Narayana 事务管理器。)
关于您的第一个问题 - 如果事务参与者提交,那么事务协调器没有任何通用的方法来撤消它。如果 2PC 发生差异(一些参与者提交而其他参与者失败),则事务协调器会宣布启发式异常,并由管理员手动修复。是的,也许您需要使用一些内部数据库日志以防万一。
但是 2PC 谈到了 2 个阶段,第一个阶段在这里是相关的。如果所有参与者都从准备阶段返回 OK,则意味着所有参与者都在其内部事务日志中创建了一条记录。在数据库的情况下,当事务准备好并且某些行被锁定以更改其他事务时。DB 然后等待协调器驱动提交。如果 DB 没有得到提交命令,它会等待 - 从协调器到 DB 的 egif 连接被中断,然后等待连接再次启动。即使该事务协调器未能及时完成事务(因为连接崩溃),它也会(可能)在连接再次启动时完成其工作。
现在取决于发生了什么故障。连接崩溃的例子被认为是一个临时的动作,事务协调器可以在连接建立后完成工作。如果有一些严重的问题,那么参与者会将有关它的信息返回给事务协调器,然后它会用上面提到的启发式异常通知给用户。
就是这样 - 如果您的第二个问题指出,一个参与者可能被提交而其他参与者被回滚。