saga模式下,事务正常执行完成,seata全局事务表里该事务记录超期后,seata会执行回滚逻辑

vlurs2pr  于 22天前  发布在  其他
关注(0)|答案(4)|浏览(16)
  • I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description

我在使用seata saga模式,版本是1.5.2
以下有四个场景:
场景一:事务有异常,事务回滚成功业务库seata_state_machine_inst表中的STATUS字段为UN,compensation_status字段为SU,seata库global_table表记录了相应的全局事务,timeout字段值为1800000,三十分钟后该记录消失,没有触发回滚逻辑
场景二:事务正常执行,seata_state_machine_inst表中的STATUS字段为SU,compensation_status字段为null,seata库global_table表记录了相应的全局事务,timeout字段值为1800000,三十分钟后触发回滚逻辑
场景三:事务正常执行,seata_state_machine_inst表中的STATUS字段为SU,compensation_status字段为null,我手动给compensation_status字段填入UN值,seata库global_table表记录了相应的全局事务,timeout字段值为1800000,三十分钟后触发回滚逻辑
场景四:事务正常执行,seata_state_machine_inst表中的STATUS字段为SU,compensation_status字段为null,我手动给compensation_status字段填入SU值,seata库global_table表记录了相应的全局事务,timeout字段值为1800000,三十分钟没有触发回滚逻辑,记录消失

求助是否是我编写的saga状态机json有问题,需要显式设置一下compensation_status,还是要在回滚逻辑判断一下STATUS值,还是seata有bug,判断STATUS SU以后不应该再去读取compensation_status字段

下面这个issue描述应该和我遇到的问题一致,但是看了评论好像没完全修复
#5424

gab6jxml

gab6jxml1#

上面的4个场景,除了 5424 ,也就是场景2,其他场景是预期内的。

compensation_status标识着saga流程触发过补偿,并且记录了补偿的状态,只要触发过补偿,那么就认为是在回滚流程。SAGA状态机上报TC状态也是基于此种理念上报的,正常执行结束并且compensation_status==null,才会上报Committed状态给TC。

uidvcgyl

uidvcgyl2#

但是在seata 1.5.2版本下,事务正常执行结束并且compensation_status==null这种情况没有上报Committed,准备在业务代码里手动更新compensation_status值规避,请问有没有其他规避方案,如升降seata版本

mwyxok5s

mwyxok5s3#

seata 1.5.2版本【事务正常执行结束并且compensation_status==null】这种情况上报了Committed,只不过没有生效,这个问题在develop分支已经修复了,你可以验证下看看。

wgx48brx

wgx48brx4#

验了seata1.7.0分支 执行saga模式,正常执行完以后global_table表事务记录删除了,也没超时回滚这一说了

相关问题