raincat
raincat copied to clipboard
dromara
这个事务框架应该不能算是“二阶段提交”
作者你好，看了一下happylifeplat-transaction的实现，感觉你这个事务框架好像还不能算是“二阶段提交”啊。二阶段提交针对的是事务框架对资源管理器/数据库的协调过程，真正执行二阶段提交的应该还是底层的数据库。原理可以参考：二阶段提交原理图。 而happylifeplat-transaction在提交事务时，采用的仍然是资源管理器的一阶段提交。只不过在发起提交之前，先判断了一下节点间网络通道的状态等信息，但这种框架自己内部的判断，应该不能算是一个提交的阶段啊。不然，二阶段提交岂不是分分钟改成三阶段提交了？二阶段、三阶段也就没啥太大差别、也不具备任何意义了。不知道我理解的对不对，求解惑~
其实很简单，第一阶段，执行了业务方法，但是事务没有提交， 第二阶段，再提交事务
仔细想了一下，感觉很绕，这个说法还是不能让人信服。如果业务方法执行算第一个阶段，事务提交算第二个阶段，那不是所有的事务机制都是”两阶段提交“了吗？毕竟，业务方法的执行肯定是少不了的，没有业务执行就不可能有所谓的事务处理；但是，事务提交肯定也是少不了的，否则啥都不做谈事务处理就没啥意义了。
其实很简单，第一阶段，执行了业务方法，但是事务没有提交， 第二阶段，再提交事务
仔细想了一下，感觉很绕，这个说法还是不能让人信服。如果业务方法执行算第一个阶段，事务提交算第二个阶段，那不是所有的事务机制都是”两阶段提交“了吗？毕竟，业务方法的执行肯定是少不了的，没有业务执行就不可能有所谓的事务处理；但是，事务提交肯定也是少不了的，否则啥都不做谈事务处理就没啥意义了。
你可以先看看二阶段提交的相关理论。
其实很简单，第一阶段，执行了业务方法，但是事务没有提交， 第二阶段，再提交事务
仔细想了一下，感觉很绕，这个说法还是不能让人信服。如果业务方法执行算第一个阶段，事务提交算第二个阶段，那不是所有的事务机制都是”两阶段提交“了吗？毕竟，业务方法的执行肯定是少不了的，没有业务执行就不可能有所谓的事务处理；但是，事务提交肯定也是少不了的，否则啥都不做谈事务处理就没啥意义了。
你可以先看看二阶段提交的相关理论。
我也是看过了才过来讨论的好吧？我还贴了张图。 我说的有什么地方不对的，直接指出来讨论呗。有什么我们不知道的，你指出来大家看到了也就学到了，难道框架开源出来，不是以让人学习为目的的吗？ 不然，别人都提出问题了，先不说存不存在这个问题只打发别人去学习，这就是回避问题的态度了。
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
看这个图，第一阶段应该还不是协调者问参与者，而是事物管理器问资源管理器。而且，也不是问他是不是可以参与，而是问资源管理器有没有准备就绪，我看过网上一些文章说这个时候资源管理器应该是有数据要做持久化的，是两阶段提交的关键。 但是呢，咱们这个raincat就没有这个第一阶段，所以我才说raincat不能算两阶段提交。虽然raincat在commit之前也会判断一下各节点连接的状态，但是，这顶多是框架内部的判断，就好像自己左手和右手握手达成协议一样，是没什么意义的。
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
看这个图，第一阶段应该还不是协调者问参与者，而是事物管理器问资源管理器。而且，也不是问他是不是可以参与，而是问资源管理器有没有准备就绪，我看过网上一些文章说这个时候资源管理器应该是有数据要做持久化的，是两阶段提交的关键。 但是呢，咱们这个raincat就没有这个第一阶段，所以我才说raincat不能算两阶段提交。虽然raincat在commit之前也会判断一下各节点连接的状态，但是，这顶多是框架内部的判断，就好像自己左手和右手握手达成协议一样，是没什么意义的。
老哥, 你说的没错, 但是你有没有想过是谁触发了事物管理器去问资源管理器, 必然是出现了第一位事务的协调者, 来通知事物管理器需要开始进入第一阶段的准备工作了, 由协调者委托事物管理器去问参与者是否准备好, raincat唯一和2PC协议不一样的是, 参与者不是预先知道的, 而是边执行边知道的, 后续的并没什么区别.
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
看这个图，第一阶段应该还不是协调者问参与者，而是事物管理器问资源管理器。而且，也不是问他是不是可以参与，而是问资源管理器有没有准备就绪，我看过网上一些文章说这个时候资源管理器应该是有数据要做持久化的，是两阶段提交的关键。 但是呢，咱们这个raincat就没有这个第一阶段，所以我才说raincat不能算两阶段提交。虽然raincat在commit之前也会判断一下各节点连接的状态，但是，这顶多是框架内部的判断，就好像自己左手和右手握手达成协议一样，是没什么意义的。
老哥, 你说的没错, 但是你有没有想过是谁触发了事物管理器去问资源管理器, 必然是出现了第一位事务的协调者, 来通知事物管理器需要开始进入第一阶段的准备工作了, 由协调者委托事物管理器去问参与者是否准备好, raincat唯一和2PC协议不一样的是, 参与者不是预先知道的, 而是边执行边知道的, 后续的并没什么区别.
你所说的协调者本身就是事务管理器的一个角色好不好，你把它从事务管理器中单独提出来并不能改变它的角色。想想看，能协调事务的不是事务管理器，是什么？？？
参与者既可能是事务管理器也可能是资源管理器。无论怎么样2PC都是事务管理器和资源管理器之间的协议，因为事务管理器之间的2PC最终都必须要落到对资源管理器的操作上。
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
看这个图，第一阶段应该还不是协调者问参与者，而是事物管理器问资源管理器。而且，也不是问他是不是可以参与，而是问资源管理器有没有准备就绪，我看过网上一些文章说这个时候资源管理器应该是有数据要做持久化的，是两阶段提交的关键。 但是呢，咱们这个raincat就没有这个第一阶段，所以我才说raincat不能算两阶段提交。虽然raincat在commit之前也会判断一下各节点连接的状态，但是，这顶多是框架内部的判断，就好像自己左手和右手握手达成协议一样，是没什么意义的。
老哥, 你说的没错, 但是你有没有想过是谁触发了事物管理器去问资源管理器, 必然是出现了第一位事务的协调者, 来通知事物管理器需要开始进入第一阶段的准备工作了, 由协调者委托事物管理器去问参与者是否准备好, raincat唯一和2PC协议不一样的是, 参与者不是预先知道的, 而是边执行边知道的, 后续的并没什么区别.
你所说的协调者本身就是事务管理器的一个角色好不好，你把它从事务管理器中单独提出来并不能改变它的角色。想想看，能协调事务的不是事务管理器，是什么？？？
参与者既可能是事务管理器也可能是资源管理器。无论怎么样2PC都是事务管理器和资源管理器之间的协议，因为事务管理器之间的2PC最终都必须要落到对资源管理器的操作上。
不好意思, 说错了, 应该是发起者而不是协调者. 协议本身并没规定每个阶段具体实现的细节是什么, 如第一阶段, 协议只规定参与者需要告知协调者预提交阶段是否成功, 以此来决定后续的操作是提交还是回滚. 其次如果你有仔细看raincat的源码的话, 会发现它不仅需要保证节点之间的通信是否畅通, 还要保证每个阶段的业务操作是否成功, 才会通知协调者是否可以进行提交或回滚
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
看这个图，第一阶段应该还不是协调者问参与者，而是事物管理器问资源管理器。而且，也不是问他是不是可以参与，而是问资源管理器有没有准备就绪，我看过网上一些文章说这个时候资源管理器应该是有数据要做持久化的，是两阶段提交的关键。 但是呢，咱们这个raincat就没有这个第一阶段，所以我才说raincat不能算两阶段提交。虽然raincat在commit之前也会判断一下各节点连接的状态，但是，这顶多是框架内部的判断，就好像自己左手和右手握手达成协议一样，是没什么意义的。
老哥, 你说的没错, 但是你有没有想过是谁触发了事物管理器去问资源管理器, 必然是出现了第一位事务的协调者, 来通知事物管理器需要开始进入第一阶段的准备工作了, 由协调者委托事物管理器去问参与者是否准备好, raincat唯一和2PC协议不一样的是, 参与者不是预先知道的, 而是边执行边知道的, 后续的并没什么区别.
你所说的协调者本身就是事务管理器的一个角色好不好，你把它从事务管理器中单独提出来并不能改变它的角色。想想看，能协调事务的不是事务管理器，是什么？？？ 参与者既可能是事务管理器也可能是资源管理器。无论怎么样2PC都是事务管理器和资源管理器之间的协议，因为事务管理器之间的2PC最终都必须要落到对资源管理器的操作上。
不好意思, 说错了, 应该是发起者而不是协调者. 协议本身并没规定每个阶段具体实现的细节是什么, 如第一阶段, 协议只规定参与者需要告知协调者预提交阶段是否成功, 以此来决定后续的操作是提交还是回滚. 其次如果你有仔细看raincat的源码的话, 会发现它不仅需要保证节点之间的通信是否畅通, 还要保证每个阶段的业务操作是否成功, 才会通知协调者是否可以进行提交或回滚
raincat参与者可以告诉raincat协调者预提交阶段成功与否，但是raincat参与者管理的DB会告知raincat参与者预提交成功与否么？raincat参与者判断DB实例在预提交阶段都成功了之后，DB又出现故障了呢？raincat参与者不是就直接抓瞎了？后续raincat协调者要是决定回滚还好，要是决定提交，直接就是事务不一致了（raincat协调者可能不止协调一个raincat参与者，其他参与者管理的DB很可能就提交了）。
你所说的节点之间的通讯是否通畅，这是实现层面上要考虑的事情。raincat是原理上有问题，也就是说，在假设节点之间永远是通畅这一前提下，raincat的机制仍然是有问题的。因为它的2PC仅仅是在raincat的节点之间，但是raincat和DB之间不是2PC。你在上层搞2PC，架不住底层DB把你当1PC啊。没有底层DB的支撑，上层的所谓“两阶段提交”就显得自作动情了，就像上面举得那个例子一样。
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
看这个图，第一阶段应该还不是协调者问参与者，而是事物管理器问资源管理器。而且，也不是问他是不是可以参与，而是问资源管理器有没有准备就绪，我看过网上一些文章说这个时候资源管理器应该是有数据要做持久化的，是两阶段提交的关键。 但是呢，咱们这个raincat就没有这个第一阶段，所以我才说raincat不能算两阶段提交。虽然raincat在commit之前也会判断一下各节点连接的状态，但是，这顶多是框架内部的判断，就好像自己左手和右手握手达成协议一样，是没什么意义的。
老哥, 你说的没错, 但是你有没有想过是谁触发了事物管理器去问资源管理器, 必然是出现了第一位事务的协调者, 来通知事物管理器需要开始进入第一阶段的准备工作了, 由协调者委托事物管理器去问参与者是否准备好, raincat唯一和2PC协议不一样的是, 参与者不是预先知道的, 而是边执行边知道的, 后续的并没什么区别.
你所说的协调者本身就是事务管理器的一个角色好不好，你把它从事务管理器中单独提出来并不能改变它的角色。想想看，能协调事务的不是事务管理器，是什么？？？ 参与者既可能是事务管理器也可能是资源管理器。无论怎么样2PC都是事务管理器和资源管理器之间的协议，因为事务管理器之间的2PC最终都必须要落到对资源管理器的操作上。
不好意思, 说错了, 应该是发起者而不是协调者. 协议本身并没规定每个阶段具体实现的细节是什么, 如第一阶段, 协议只规定参与者需要告知协调者预提交阶段是否成功, 以此来决定后续的操作是提交还是回滚. 其次如果你有仔细看raincat的源码的话, 会发现它不仅需要保证节点之间的通信是否畅通, 还要保证每个阶段的业务操作是否成功, 才会通知协调者是否可以进行提交或回滚
raincat参与者可以告诉raincat协调者预提交阶段成功与否，但是raincat参与者管理的DB会告知raincat参与者预提交成功与否么？raincat参与者判断DB实例在预提交阶段都成功了之后，DB又出现故障了呢？raincat参与者不是就直接抓瞎了？后续raincat协调者要是决定回滚还好，要是决定提交，直接就是事务不一致了（raincat协调者可能不止协调一个raincat参与者，其他参与者管理的DB很可能就提交了）。
你所说的节点之间的通讯是否通畅，这是实现层面上要考虑的事情。raincat是原理上有问题，也就是说，在假设节点之间永远是通畅这一前提下，raincat的机制仍然是有问题的。因为它的2PC仅仅是在raincat的节点之间，但是raincat和DB之间不是2PC。你在上层搞2PC，架不住底层DB把你当1PC啊。没有底层DB的支撑，上层的所谓“两阶段提交”就显得自作动情了，就像上面举得那个例子一样。
那如果按照你这么说, 目前几乎所有的2PC方案实际都是1PC, 都是抓瞎?
你的图中二阶段提交，第一阶段中，一开始协调者就去问所有的参与者是否可以进行参与。我们这个raincat是没有这个流程的，因为我们一开始不知道有哪些参与者，只能边业务执行的时候，边将所有的参与者加入到一个事务组之中。
看这个图，第一阶段应该还不是协调者问参与者，而是事物管理器问资源管理器。而且，也不是问他是不是可以参与，而是问资源管理器有没有准备就绪，我看过网上一些文章说这个时候资源管理器应该是有数据要做持久化的，是两阶段提交的关键。 但是呢，咱们这个raincat就没有这个第一阶段，所以我才说raincat不能算两阶段提交。虽然raincat在commit之前也会判断一下各节点连接的状态，但是，这顶多是框架内部的判断，就好像自己左手和右手握手达成协议一样，是没什么意义的。
老哥, 你说的没错, 但是你有没有想过是谁触发了事物管理器去问资源管理器, 必然是出现了第一位事务的协调者, 来通知事物管理器需要开始进入第一阶段的准备工作了, 由协调者委托事物管理器去问参与者是否准备好, raincat唯一和2PC协议不一样的是, 参与者不是预先知道的, 而是边执行边知道的, 后续的并没什么区别.
你所说的协调者本身就是事务管理器的一个角色好不好，你把它从事务管理器中单独提出来并不能改变它的角色。想想看，能协调事务的不是事务管理器，是什么？？？ 参与者既可能是事务管理器也可能是资源管理器。无论怎么样2PC都是事务管理器和资源管理器之间的协议，因为事务管理器之间的2PC最终都必须要落到对资源管理器的操作上。
不好意思, 说错了, 应该是发起者而不是协调者. 协议本身并没规定每个阶段具体实现的细节是什么, 如第一阶段, 协议只规定参与者需要告知协调者预提交阶段是否成功, 以此来决定后续的操作是提交还是回滚. 其次如果你有仔细看raincat的源码的话, 会发现它不仅需要保证节点之间的通信是否畅通, 还要保证每个阶段的业务操作是否成功, 才会通知协调者是否可以进行提交或回滚
raincat参与者可以告诉raincat协调者预提交阶段成功与否，但是raincat参与者管理的DB会告知raincat参与者预提交成功与否么？raincat参与者判断DB实例在预提交阶段都成功了之后，DB又出现故障了呢？raincat参与者不是就直接抓瞎了？后续raincat协调者要是决定回滚还好，要是决定提交，直接就是事务不一致了（raincat协调者可能不止协调一个raincat参与者，其他参与者管理的DB很可能就提交了）。 你所说的节点之间的通讯是否通畅，这是实现层面上要考虑的事情。raincat是原理上有问题，也就是说，在假设节点之间永远是通畅这一前提下，raincat的机制仍然是有问题的。因为它的2PC仅仅是在raincat的节点之间，但是raincat和DB之间不是2PC。你在上层搞2PC，架不住底层DB把你当1PC啊。没有底层DB的支撑，上层的所谓“两阶段提交”就显得自作动情了，就像上面举得那个例子一样。
那如果按照你这么说, 目前几乎所有的2PC方案实际都是1PC, 都是抓瞎?
本issue只说Raincat是冒充的2PC吧，它本质是1PC，如果你一定要用抓瞎这个词的话，那它就是。
谁说所有的2PC方案实际都是1PC了？这话有语病你不觉得么？2PC就是2PC，怎么会实际上都是1PC？真正的2PC方案多了，atomikos、narayana、jotm、bitronix都是正宗的2PC方案，他们实质都是2PC而不是1PC。
raincat的2pc本质是，你执行的业务方法，比如insert，update，这个结果并不会马上提交，等到所有的流程执行完成，txmanage发通知给业务方，这个时候也会真正的提交，不知道你们明白了没有？
raincat的2pc本质是，你执行的业务方法，比如insert，update，这个结果并不会马上提交，等到所有的流程执行完成，txmanage发通知给业务方，这个时候也会真正的提交，不知道你们明白了没有？
这个issue质疑的正是和这相关。insert/update的执行当然不会马上提交，马上提交的那是auto-commit，没事务的那种。raincat的txmanager发通知给业务方，业务方的提交是一次性执行的，因此是1pc。2pc的本质，需要tm针对数据库做prepare，commit两个操作来完成事务，见2pc原理图。这一点在raincat中是不涉及的，因此我才说它不能算2pc。