5
一、A服务调用B服务
A服务主要代码：
B服务主要代码：
二、数据库原数据
三、异常回滚记录如下：
四、B服务undo_log的rollback_info
我的问题是：
1、为什么不能正常回滚（如果不设置tradeOrderLuw.set(TradeOrder::getRefundAt, "9")就可以正常回滚）
LambdaUpdateWrapper
谢谢
Q
[seata]重复回滚的奇怪问题
A
回答
2
版本： shardingsphere 4.1.1 spring-cloud-starter-alibaba-seata 2.1.0.RELEASE seata-spring-boot-starter 1.4.2
6
Field not equals, name refund_at, old value 9, new value 2022-04-27 23:39:13 检查是不是数据库层面开启自动更新时间戳,如果是等待1.5发版解决这个问题,再次之前
Q: 28. 数据库开启自动更新时间戳导致脏数据无法回滚？ A:
由于业务提交，seata记录当前镜像后，数据库又进行了一次时间戳的更新，导致镜像校验不通过。
解决方案1:关闭数据库的时间戳自动更新。数据的时间戳更新，如修改、创建时间由代码层面去维护，比如MybatisPlus就能做自动填充。
解决方案2:update语句别把没更新的字段也放入更新语句。
8
由于业务提交，seata记录当前镜像后，数据库又进行了一次时间戳的更新，导致镜像校验不通过。
解决方案1:关闭数据库的时间戳自动更新。数据的时间戳更新，如修改、创建时间由代码层面去维护，比如MybatisPlus就能做自动填充。
解决方案2:update语句别把没更新的字段也放入更新语句。
您好，我也怕因为以上问题引起，我还故意修改字段的名称，由原来的callback_refund_at改为refund_at,也全局搜索并没有mybatis-plus自动填充，我也把时间戳的格式改为char格式，问题还是没能解决，也没有多事务在竞争，我也简化A、B服务，只是简单的测试 谢谢
3
- 你的第三点和第四点可以看出不是同一个分支事物，所以需要你帮忙提供（确认）一下，是同一个undo_log记录的内容
- 看你的datasource层级，应该是seata在ss上面，所以ss的日志应该是很全的，希望你可以提供更完整的第三点的日志
8
1.你的第三点和第四点可以看出不是同一个分支事物，所以需要你帮忙提供（确认）一下，是同一个undo_log记录的内容 2.看你的datasource层级，应该是seata在ss上面，所以ss的日志应该是很全的，希望你可以提供更完整的第三点的日志
你好，不是在一个分支事务，我是分布式事务进行测试 我调试跟踪发现可能是tablemeta数据有问题
调试跟踪截图：
数据库数据截图：
4
如果我的猜测没错的话，这个问题应该是在1.5.0修复了，具体需要你自己试验一下，或者提供更详细的日志等内容我们也可以进一步确定
9
关闭数据库的时间戳自动更新。数据的时间戳更新，如修改、创建时间由代码层面去维护，比如MybatisPlus就能做自动填充。 不是让你找自己代码里的自动填充