当一个数据源事务失败时，Spring 无法回滚已提交的事务

Question

我正在开发一项微服务，其中涉及多个数据源。为了简化起见，我在这里使用两个数据源：MySql 和 Oracle。这是伪代码。

    domain.withNewTransaction {

      mySql.executeUpdate("update mySqlTable")

      oracle.executeUpdate("update oracleTable")

    }

有一天，在尝试提交oracle更新时出现异常，但是我发现mysql更新已成功提交并且没有回滚。我发现该框架正在使用ChainedTransactionManager.java来管理多个数据源提交。这是commit方法的代码。

public void commit(TransactionStatus status) throws TransactionException {

        MultiTransactionStatus multiTransactionStatus = (MultiTransactionStatus) status;

        boolean commit = true;

        Exception commitException = null;

        PlatformTransactionManager commitExceptionTransactionManager = null;

        for (PlatformTransactionManager transactionManager : reverse(transactionManagers)) {

            if (commit) {

                try {

                    multiTransactionStatus.commit(transactionManager);

                } catch (Exception ex) {

                    commit = false;

                    commitException = ex;

                    commitExceptionTransactionManager = transactionManager;

                }

            } else {

                // after unsucessfull commit we must try to rollback remaining transaction managers

                try {

                    multiTransactionStatus.rollback(transactionManager);

                } catch (Exception ex) {

                    LOGGER.warn("Rollback exception (after commit) (" + transactionManager + ") " + ex.getMessage(), ex);

                }

            }

        }

事实证明，当一个数据源提交失败时，ChainedTransactionManager 只会回滚剩余未提交的数据源，与已提交的事务无关。

我知道回滚已提交的事务是复杂且有风险的。我想知道应用程序开发人员是否有更好的想法来处理多数据源事务提交失败。提前致谢！

Answer 1

跨多个数据源的事务Grails 使用 Best Efforts 1PC 模式来处理跨多个数据源的事务。Best Efforts 1PC 模式相当通用，但在开发人员必须注意的某些情况下可能会失败。这是一种非 XA 模式，涉及多个资源的同步单阶段提交。由于未使用 2PC，因此它永远不可能像 XA 事务那样安全，但如果参与者意识到其中的妥协，通常就足够好了。基本思想是在事务中尽可能晚地延迟所有资源的提交，以便唯一可能出错的事情是基础设施故障（而不是业务处理错误）。依赖 Best Efforts 1PC 的系统认为基础设施故障很少见，因此它们有能力承担风险以换取更高的吞吐量。如果业务处理服务也被设计为幂等的，那么在实践中就不会出错。BE1PC 实现是在 Grails 2.3.6 中添加的。。在此更改之前，其他数据源不会参与 Grails 中启动的事务。附加数据源中的事务基本上处于自动提交模式。在某些情况下，这可能是想要的行为。一个原因可能是性能：在每个新事务开始时，BE1PC 事务管理器都会为每个数据源创建一个新事务。通过在附加数据源的相应配置块中设置 transactional = false，可以将附加数据源保留在 BE1PC 事务管理器之外。readOnly = true 的数据源也将被排除在链式事务管理器之外（自 2.3.7 起）。默认情况下，BE1PC 实现会将所有实现 Spring PlatformTransactionManager 接口的 bean 添加到链式 BE1PC 事务管理器中。例如，Grails 应用程序上下文中可能的 JMSTransactionManager bean 将被添加到 Grails BE1PC 事务管理器的事务管理器链中。您可以使用以下配置选项从 BE1PC 实现中排除事务管理器 bean：grails.transaction.chainedTransactionManagerPostProcessor.blacklistPattern = '.*' 排除匹配是在事务管理器 bean 的名称上完成的。将跳过 transactional = false 或 readOnly = true 的数据源的事务管理器，在这种情况下不需要使用此配置选项。XA 和两阶段提交 当尽力而为 1PC 模式不适合处理跨多个事务资源（不仅是数据源）的事务时，可以使用多种选项来向 Grails 应用程序添加 XA/2PC 支持。Spring 事务文档包含有关集成不同应用程序服务器的 JTA/XA 事务管理器的信息。在这种情况下，您可以在 resources.groovy 或 resources.xml 文件中手动配置名为 transactionManager 的 bean。还有 Atomikos 插件可用于 Grails 应用程序中的 XA 支持。