@Transactional和@DS如何在事务中切换数据源

最新推荐文章于 2025-03-21 16:21:50 发布

Abstracted

最新推荐文章于 2025-03-21 16:21:50 发布

阅读量6.6k

点赞数 14

分类专栏：学习笔记文章标签： spring 后端 spring boot

本文链接：https://blog.youkuaiyun.com/qq_16159433/article/details/120951554

版权

学习笔记专栏收录该内容

32 篇文章

订阅专栏

本文详细分析了在Spring中使用@DS数据源切换与@Transactional事务管理时遇到的问题。当在一个Service方法中同时操作多个数据源并期望保持事务原子性时，由于动态数据源路由和事务管理器的交互，可能导致事务使用了错误的数据源。解决方案是在需要切换数据源的方法上添加@DS和@Transactional，并设置Propagation.REQUIRES_NEW，确保每个数据源的操作在独立的事务中进行，以避免数据源混乱导致的异常。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

在一次需求中，需要对两个数据库进行读写操作，并且要保证对这两个库的操作的原子性。所以就在一个service方法中加入了@Transaction,方法中包含了对两个库的操作。

spring:
  datasource:
    dynamic:
      primary: A 
      datasource:
        A:
          url:..
          driver-class-name: com.mysql.jdbc.Driver
          username: root
          password:
        B:
          url: ..
          driver-class-name: com.mysql.jdbc.Driver
          username: root
          password:
        C:
          url: ..
          driver-class-name: com.mysql.jdbc.Driver
          username: root
          password:

@Mapper
@DS("A")
public interface AMapper{
      @Insert("insert into a ...")
      void save();
}

@Mapper
@DS("B")
public interface BMapper{
      @Insert("insert into b ...")
      void save();
}

public class aService{

@Autowired
private aMapper、bMapper、cMapper

    @Transactional
    public void save(){
	    aMapper.save();
	    bMapper.save(); #报错
    }    
}

在执行测试时bMapper.save()发生了错误，报错信息：找不到b表，很明显sql是从A库中找b表，当然会报错找不到b表。如果把@Transactional注解去掉就可以正常运行，数据也成功分别写入两个库中。但是我们命名已经在2个Mapper上加了@Ds()注解来切换要是用的数据源，那为什么加入了事务就报错了呢？

@Transactional执行流程

save方法添加了 @Transactional 注解，Spring 事务就会生效。此时，Spring TransactionInterceptor 会通过 AOP 拦截该方法，创建事务。而创建事务，势必就会获得数据源。那么，TransactionInterceptor 会使用 Spring DataSourceTransactionManager 创建事务，并将事务信息通过 ThreadLocal 绑定在当前线程。
而事务信息，就包括事务对应的 Connection 连接。那也就意味着，还没走到 OrderMapper 的查询操作，Connection 就已经被创建出来了。并且，因为事务信息会和当前线程绑定在一起，在 OrderMapper 在查询操作需要获得 Connection 时，就直接拿到当前线程绑定的 Connection ，而不是 OrderMapper 添加 @DS 注解所对应的 DataSource 所对应的 Connection 。
OK ，那么我们现在可以把问题聚焦到 DataSourceTransactionManager 是怎么获取 DataSource 从而获得 Connection 的了。对于每个 DataSourceTransactionManager 数据库事务管理器，创建时都会传入其需要管理的 DataSource 数据源。在使用 dynamic-datasource-spring-boot-starter 时，它创建了一个 DynamicRoutingDataSource ，传入到 DataSourceTransactionManager 中。
而 DynamicRoutingDataSource 负责管理我们配置的多个数据源。例如说，本示例中就管理了 a、b两个数据源，并且默认使用 a 数据源。那么在当前场景下，DynamicRoutingDataSource 需要基于 @DS 获得数据源名，从而获得对应的 DataSource ，结果因为我们在 Service 方法上，并没有添加 @DS 注解，所以它只好返回默认数据源，也就是 a 。故此，就发生了找不到表的异常。

我们在上面了解到，因为@Transactional会创建事务然后获得数据源，因为我们service方法上没有@DS注解，就拿了默认数据源，并且在这之后，这个事务信息会通过threadLocal跟当前线程绑定，事务信息包括了connection连接，也就意味着，在进入这个service方法的时候，当前事务就绑定了数据源a，在运行到bMapper.save()时，因为connection已经存在，所以拿到的数据源还是a，这时候就找不到b库里的表了。

解决方法

把对B库操作的方法都加上@DS和 @Transactional注解（在service上加）。ps:在完成了aMapper.save()之后去调用bMapper.save()时，一定要把@Transactional设置为Propagation.REQUIRES_NEW，这样在调用另一个事务方法时，TransactionInterceptor 会将原事务挂起，暂时性的将原事务信息和当前线程解绑，然后创建一个新的事务，并且从数据源中取出一个connection链接，而此时的数据源已经被切换成我们需要的数据源。如果B操作发生了异常，B事务将回滚并将异常进行抛出到A，A事务自然也会回滚。

在对B库的操作如果不需要事务的话，可以在对B库操作的方法上指定事务的隔离级别为NOT_SUPPORTED，这样执行到该方法时会暂停挂起当前事务，等待对B库的方法执行完毕再恢复事务。

pps：当前事务方法里用this来调用另一个事务方法时，当前这个事务方法的@DS也会起作用，原因是@Ds是基于AOP切面在方法执行前切换数据源，而this调用的不是通过代理生成的事务对象，而是自己本身的原对象，不会开启事务。