更改事务状态时，db/redis模式必须是线程安全的
db/redis模式需串行更改事务状态,假设事务A在tm端进行决议提交，此时到达了tc端，而tc端刚好发现这个事务达到了超时，就会更改状态为超时回滚，而这两个动作是并行的，导致决议提交时删除了全局锁，又恰好被改为超时回滚，导致分支事务被回滚，回滚时可能会发现数据已经无法对上了（全局锁被删了）
1.redis可使用锁+读+改的方式或lua脚本来保证原子性修改
2.db模式可以使用乐观锁形式，updatestatus时，必须现在的status是当前globalsession的status否则要失败 有其他更好的方案欢迎讨论
其实是不是参照file，扩展两个加锁的策略就行了
原提问者GitHub用户a364176773
写回答
-
你说的是仿照FileTransactionStoreManager，在writeSession里面直接加一个对应的分布式锁吗？我想过这个方式，但是这样似乎防止不了互相覆盖，假如commit线程去更新完成才发生rollback线程去更新的话，commit的时候执行成功了也往下走，rollback的时候执行成功也往下走。最终数据还是会不一致。
我现在也算是在扩展加锁的策略，但思路是拿到global的预期状态（begin），然后往下传到writeSession，再在这里面用乐观锁的方式去更新global的表，成功的往下走，不成功的抛异常。
原回答者GitHub用户Bughue
2023-06-14 17:31:41赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践，通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式，助力制造业企业高效上云，实现系统稳定、应用敏捷智能。拥抱云原生，让创新无处不在。
