For example, for a branch transaction, the user performs a delete operation, then the prepare phase is committed, but the global transaction fails, causing the rollback. // 比如某个分支事务,用户执行了 delete 操作,那么 prepare 阶段,提交了,但是全局事务失败,导致回滚
The current practice is to get all the SQL statements executed by the user through the proxy connection, save before, and atfer image in the undo_log table. // 目前的做法是通过 代理 connection,拿到用户执行的所有sql语句,保存 before,atfer image 在 undo_log 表中。 If you submit, pass gxid, bxid delete data undo_log // 如果提交就通过 gxid, bxid 删除数据undo_log If it fails, the data is rolled back to get the before image. // 如果失败了,就数据回退搞 before image . However, delete succeeded, but the global transaction failed, but other transactions, before the rollback, insert the same key data, resulting in the failure to roll back? Either the xa transaction is used, and the data of these changes cannot be modified before the commit/rollback. // 但是 delete 成功了,但是全局事务失败,但是其他事务,在回滚前,insert了相同key的数据,导致无法回滚? 要么就是采用 xa 事务,这些变更的数据,commit/rollback 前没法修改。
原提问者GitHub用户rongyingjie
我看了下lockkey的机制是服务端维护的一个锁并非数据库层面的,所以这个锁仅针对fescar发起的事务有效。如上例子A事务包含BCD分支,需要修改TableA,后续事务如果想修改TableA就需要经过lockkey检查,直到A事务释放锁。如果有一个业务操作没有发起事务也去修改TableA,这个是不需要lockkey检查的。如有错误请纠正
原回答者GitHub用户Yuanxiangz
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。