前言

在开发企业级应用时，使用多数据源是一个常见需求。而MyBatis-Plus作为一个优秀的ORM框架，为我们提供了便捷的多数据源配置。但是，在实际使用过程中，我们遇到了一些问题。本文将详细解析这些问题的原因，并提供解决方案。

问题描述

在使用MyBatis-Plus框架配置多数据源后，我们可以通过@DataSource注解来声明某个方法使用特定的数据源。然而，我们发现在某些情况下，即使我们使用了@DataSource注解，方法仍然使用的是默认的数据源。

经过一番排查，我们发现这是因为方法上使用了@Transaction注解。由于@Transaction注解会在方法执行之前就开启事务，因此在声明数据源之前，事务管理器已经绑定了默认的数据源。

原因分析

数据源声明失败的原因

在Spring的事务管理中，@Transaction注解会在目标方法执行之前开启事务，并绑定一个事务上下文。事务上下文是与当前线程绑定的，因此在方法执行期间，所有的数据库操作都会使用同一个事务上下文。

由于@Transaction注解是在目标方法执行之前就绑定了事务上下文，因此如果此时未明确指定数据源，默认的数据源就会被选定。一旦事务上下文与默认数据源绑定，在方法执行过程中，即使后续声明了其它数据源，也无法更改已经绑定的数据源。

@Transaction注解提前绑定数据源的原因

@Transaction注解的处理逻辑是在Spring的事务拦截器中实现的。当一个方法被@Transaction注解标记时，Spring会通过AOP的方式在方法执行前后进行事务管理。

在方法执行之前，Spring事务拦截器会通过TransactionManager开启一个新的事务，并将事务信息绑定到当前线程的上下文中，这就导致了数据源的提前绑定。

解决方案

为了确保在使用@Transaction注解时仍能正确选择数据源，可以在@Transaction注解中指定相应的事务管理器。具体实现如下：

@Service
public class MyService {

    @DataSource("dataSource1")
    @Transactional(transactionManager = "transactionManager1")
    public void myMethod() {
        // ...业务逻辑...
    }
}

在上述代码中，我们在@Transactional注解中指定了transactionManager1，这样就可以确保在方法执行前事务管理器绑定的是我们期望的数据源。

总结

在使用MyBatis-Plus配置多数据源时，务必注意@Transaction注解的使用。由于@Transaction注解会在方法执行之前绑定事务上下文，因此需要在注解中显式指定事务管理器，以避免数据源的错误绑定。

通过本文的分析和解决方案，希望能帮助开发者们更好地理解MyBatis-Plus中的多数据源配置及其与事务管理的关系。