4
上图中，一阶段业务逻辑如果有异常，会回滚，一阶段的fence_log实际上插入失败了，在回滚过程中，会判断没有fence_log，不执行cancel逻辑，如下图
如果一阶段的业务全是能够被Spring事务管理的操作还可以，如果不是可以被Spring事务管理的操作，这里应该会有问题
Q
[seata]TCC开启围栏二阶段取消可能无法执行
A
回答
5
这就是特意这么做防悬挂的，一阶段没有的fence记录就插入一条记录防止资源悬挂
2
这个不是悬挂，事实上是prepare阶段执行了，但是出错了，但是因为事务回滚，tried的记录没有插入，到二阶段，rollback中由于没这个记录，会被认为prepare阶段没执行，做了一个空回滚，实际上不是悬挂
9
tcc应该是prepare commit cancel，职责是单一的行为，当prepare都失败何必进行cancel？本地事务就回滚了，否则如果一阶段什么都没执行的情况下挂了，执行cancel去会发生什么问题也未可知？
5
这个我理解，我想的是如果prepare阶段的操作不会被本地事务管理，比如redis，这种情况只能在一阶段自主做处理了
2
xdm，我先把之前那个pr链接贴上了 https://github.com/seata/seata/pull/4532
6
实际上，设置fence_log的逻辑是用在关系型数据库上的，不适合纯redis等操作。
5
因为对框架而言不知道是一阶段回滚了还是出现悬挂风险，所以还是为了防悬挂就会插入一条防悬挂数据
7
感谢两位大佬解答