开发者社区 > 云原生 > 正文

事务回滚问题

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

展开
收起
学习娃 2023-06-14 16:50:50 36 0
1 条回答
写回答
取消 提交回答
  • 我看了下lockkey的机制是服务端维护的一个锁并非数据库层面的,所以这个锁仅针对fescar发起的事务有效。如上例子A事务包含BCD分支,需要修改TableA,后续事务如果想修改TableA就需要经过lockkey检查,直到A事务释放锁。如果有一个业务操作没有发起事务也去修改TableA,这个是不需要lockkey检查的。如有错误请纠正

    原回答者GitHub用户Yuanxiangz

    2023-06-14 17:25:56
    赞同 展开评论 打赏
问答分类:
SQL
问答地址:

阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。

相关电子书

更多
低代码开发师(初级)实战教程 立即下载
冬季实战营第三期:MySQL数据库进阶实战 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载