CAICAIIs opened a new issue, #1116: URL: https://github.com/apache/incubator-seata-go/issues/1116
### ✅ 验证清单 - [x] 🔍 我已经搜索过 [现有 Issues](https://github.com/apache/incubator-seata-go/issues)，确信这不是重复请求 - [x] 📋 我已经查看了 [发布说明](https://github.com/apache/incubator-seata-go/releases)，确信此功能尚未实现 - [x] 🛠️ 我愿意自己处理这个议题 ### 🎯 功能描述 当前 `origin/master` 已经在 pr#1090 中把 XA 资源创建抽象为注册表式结构。但 Oracle 支持在多个关键点上仍然不完整： - XA 驱动 / connector / resource 初始化路径仍然明显带有 MySQL 假设 - Oracle XA 方法只是朝 `DBMS_XA` 方向搭了脚手架 - Oracle 专用的 XID 映射方案还没有定义 - Oracle 专用的错误分类与幂等语义还没有实现 - recovery 语义仍然缺失 换句话说，相比 #1056 暴露时的状态，现在的架构方向已经好很多了，但 Oracle XA 支持仍然没有真正完成。 所以目标就是，为 seata-go 提供完整的 Oracle XA 支持，包括： - Oracle 专用的 XA 资源创建与执行流程 - Oracle 兼容的 XID 编码 / 映射 - 基于 Oracle `DBMS_XA` 的分支生命周期支持 - 正确的一阶段 / 二阶段行为 - recovery 支持 - Oracle 专用的错误映射与重试 / 幂等语义 ### 📋 使用场景 典型场景包括： - 一个全局事务中有多个微服务参与，其中一个或多个分支资源由 Oracle 支撑 - 业务系统本身已经以 Oracle 作为核心事务数据库，无法切换到 MySQL 风格的 XA 行为 - 相比 AT 模式，业务更需要数据库原生的两阶段提交语义，而不是基于 undo log 的补偿机制 - 在一阶段和二阶段之间发生异常时，仍然需要保证分支提交、回滚与恢复行为正确 一个典型例子是企业里的 **订单 / 库存 / 支付 / 账户** 等流程：不同服务分别操作 Oracle 资源，而全局事务必须保证要么全部提交，要么全部回滚。 如果没有完整的 Oracle XA 支持，使用 Oracle 的 seata-go 用户就无法把 XA 模式作为一个完整且可靠的选择。 ### ⚖️ 复杂性与风险评估 _No response_ ### 🔗 外部依赖 _No response_ ### 📚 附加信息 _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
