上图中，一阶段业务逻辑如果有异常，会回滚，一阶段的fence_log实际上插入失败了，在回滚过程中，会判断没有fence_log，不执行cancel逻辑，如下图
如果一阶段的业务全是能够被Spring事务管理的操作还可以，如果不是可以被Spring事务管理的操作，这里应该会有问题
zzlelutf1#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
dly7yett2#
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
bq3bfh9z3#
tcc应该是prepare commit cancel，职责是单一的行为，当prepare都失败何必进行cancel？本地事务就回滚了，否则如果一阶段什么都没执行的情况下挂了，执行cancel去会发生什么问题也未可知？
u1ehiz5o4#
这个我理解，我想的是如果prepare阶段的操作不会被本地事务管理，比如redis，这种情况只能在一阶段自主做处理了
bgtovc5b5#
xdm，我先把之前那个pr链接贴上了 #4532
eni9jsuy6#
actually, the logic for setting fence_log is used on relational databases and is not suitable for operations such as pure redis.
bakd9h0s7#
因为对框架而言不知道是一阶段回滚了还是出现悬挂风险，所以还是为了防悬挂就会插入一条防悬挂数据
kadbb4598#
感谢两位大佬解答
8条答案
按热度按时间zzlelutf1#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
dly7yett2#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
bq3bfh9z3#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
tcc应该是prepare commit cancel，职责是单一的行为，当prepare都失败何必进行cancel？本地事务就回滚了，否则如果一阶段什么都没执行的情况下挂了，执行cancel去会发生什么问题也未可知？
u1ehiz5o4#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
tcc应该是prepare commit cancel，职责是单一的行为，当prepare都失败何必进行cancel？本地事务就回滚了，否则如果一阶段什么都没执行的情况下挂了，执行cancel去会发生什么问题也未可知？
这个我理解，我想的是如果prepare阶段的操作不会被本地事务管理，比如redis，这种情况只能在一阶段自主做处理了
bgtovc5b5#
xdm，我先把之前那个pr链接贴上了 #4532
eni9jsuy6#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
tcc应该是prepare commit cancel，职责是单一的行为，当prepare都失败何必进行cancel？本地事务就回滚了，否则如果一阶段什么都没执行的情况下挂了，执行cancel去会发生什么问题也未可知？
这个我理解，我想的是如果prepare阶段的操作不会被本地事务管理，比如redis，这种情况只能在一阶段自主做处理了
actually, the logic for setting fence_log is used on relational databases and is not suitable for operations such as pure redis.
bakd9h0s7#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
tcc应该是prepare commit cancel，职责是单一的行为，当prepare都失败何必进行cancel？本地事务就回滚了，否则如果一阶段什么都没执行的情况下挂了，执行cancel去会发生什么问题也未可知？
这个我理解，我想的是如果prepare阶段的操作不会被本地事务管理，比如redis，这种情况只能在一阶段自主做处理了
actually, the logic for setting fence_log is used on relational databases and is not suitable for operations such as pure redis.
因为对框架而言不知道是一阶段回滚了还是出现悬挂风险，所以还是为了防悬挂就会插入一条防悬挂数据
kadbb4598#
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
tcc应该是prepare commit cancel，职责是单一的行为，当prepare都失败何必进行cancel？本地事务就回滚了，否则如果一阶段什么都没执行的情况下挂了，执行cancel去会发生什么问题也未可知？
这个我理解，我想的是如果prepare阶段的操作不会被本地事务管理，比如redis，这种情况只能在一阶段自主做处理了
actually, the logic for setting fence_log is used on relational databases and is not suitable for operations such as pure redis.
因为对框架而言不知道是一阶段回滚了还是出现悬挂风险，所以还是为了防悬挂就会插入一条防悬挂数据
感谢两位大佬解答