@Transactional跟@DS动态数据源注解冲突的解决

第@Transactional跟@DS动态数据源注解冲突的解决在开发完成用postman自测时，发现bMapper.save()那一行报错了，报错内容：找不到b表。如果把@Transactional注释掉，代码正常运行，数据成功落库。我们明明在3个mapper上面都加了@DS注解来切换数据源，那为啥加了@Transactional就不行了呢？

@Transactional执行流程

save方法添加了@Transactional注解，Spring事务就会生效。此时，SpringTransactionInterceptor会通过AOP拦截该方法，创建事务。而创建事务，势必就会获得数据源。那么，TransactionInterceptor会使用SpringDataSourceTransactionManager创建事务，并将事务信息通过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、c三个数据源，并且默认使用a数据源。那么在当前场景下，DynamicRoutingDataSource需要基于@DS获得数据源名，从而获得对应的DataSource，结果因为我们在Service方法上，并没有添加@DS注解，所以它只好返回默认数据源，也就是a。故此，就发生了找不到表的异常。

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

解决方法

把这三个入库操作分为3个独立的方法，并且都加上@Transactional和@DS注解（在service上加）。ps:在完成了aMapper.save()之后去调用bMapper.save()时，一定要把@Transactional设置为Propagation.REQUIRES_NEW，这样在调用另一个事务方法时，TransactionInterceptor会将原事务挂起，暂时性的将原事务信息和当前线程解绑。

pps：

在一个事务方法里用this来调用另一个事务方法时，@DS也会起作用，原因是this调用的不是事务对象，不会开启事务。想具体了解可以看我之前发的这篇文章/