事务内动态数据源切换失效：源码解析

        笔者之前就事务和动态数据源之间的问题，做过一些探讨和总结（详见事务内动态数据源切换失效及传播属性）。后来从源码层面分析有了一些收获，篇幅较长不便写在原文中，因此另起一篇作为补充。

        注意，上篇的实验和结论依旧有效，本文旨在将理论和实践结合，给出更精确的解决方案及底层原理。

1 结论

        先上结论，帮助同样被这个问题困扰的朋友们。

        首先明确，事务控制得最小单位为“同一个数据库连接”，即想要正常控制事务回滚提交，那么整个过程只能基于一个Connection；而使用不同数据源就意味着一定对应不同的Connection，因此既要使用多数据源切换、又要使得所有数据库操作同步回滚提交，不引入分布式事务的前提下是做不到的（也许只是我做不到，如果有解决方案也可以分享）。

        其次，在事务开启时如果没有指定数据源，事务会取默认数据源并使用他，即配置文件中的primary数据源。

        基于上面的原则，结论如下：

1. 需要切换数据源的地方一定要开启新的事务，例如Service1调用Service2，如两个方法要使用不同数据源，则必须要在Service2方法上指定能够挂起原事务、开启新事务的传播属性。如使用REQUIRES_NEW、NOT_SUPPORT，强行重置数据库连接。但这也就意味着两个事务是独立的，无法同步提交/回滚。
2. 开启事务必须与指定数据源同步进行，即方法1上如果要指定非主数据源、又要开启事务，就必须把@Transactional和@DS同时加在方法上，先开事务再在里面的Mapper接口指定数据源是无效的哦。

        事务和数据源注解的用法，直接上代码。

class Service1 {

    //由于未指定数据源便开启了事务，会使用primary数据源
    @Transactional(rollbackFor = Exception.class)
    public void m1() {
        //SQL调用
    }

    //开启事务时指定了数据源，会使用datasource2数据源
    @DS("datasource2")
    @Transactional(rollbackFor = Exception.class)
    public void m2() {
        //SQL调用
    }

}

        上面为一个方法内只使用单个数据源的方式，在开启事务时就需要指定数据源，否则会默认使用主数据源；一般常用的方式是在Mapper接口上加@DS，但这种方式在这种场景下是无效的，因为事务在Service层就开启，进入Mapper哪怕切换出火花来也不好使。

class Service1 {

    //由于未指定数据源便开启了事务，会使用primary数据源
    //m3加入该事务，也会使用primary
    //m4新建事务，使用datasource2
    @Transactional(rollbackFor = Exception.class)
    public void m1() {
        //SQL调用
        Service2.m3();
        Service2.m4();
    }

    //开启事务时指定了数据源，会使用datasource2数据源
    //m3加入该事务，也会使用datasource2
    //m4新建事务，使用datasource3
    @DS("datasource2")
    @Transactional(rollbackFor = Exception.class)
    public void m2() {
        //SQL调用
        Service2.m3();
        Service2.m4();
    }

}

class Service2 {

    //默认传播属性，加入已有事务
    @DS("datasource2")
    @Transactional(rollbackFor = Exception.class)
    public void m3() {
        //SQL调用
    }

    //REQUIRES_NEW，挂起原事务，开启新事务
    @DS("datasource3")
    @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
    public void m4() {
        //SQL调用
    }

}

        上述代码一个方法内多次切换数据源，首先一定要确保是注入Bean来调用方法，否则加啥注解也不好使，动态代理会直接失效。

        先看m1()，没有指定数据源所以使用primary数据源，调用得m3()使用了默认的REQUIRED传播属性，会加入m1()的事务一起使用primary，因此m3()上的数据源切换失效；而m4()使用了REQUIRES_NEW，挂起了m1()开启的事务并新建了事务，开启事务的同时指定了数据源datasource3，因此m4()不会受任何人影响做自己想做的。

        m2()类似，会使m3()使用m2()开启时指定的datasource2，m4()用自己的datasource3。

2 源码解析

        结论有了，自然也要有辩证的过程，矛盾集中在@Transactional和@DS同时使用，因此我们要整明白这两个注解都干了什么、哪一步产生了冲突、又该如何解决这种冲突，我们来一步一步盘。

2.1 方法代理

        断点加在从Controller跳转到Service实现类中间，因为Spring注解采用了AOP动态代理来实现功能增强，那连接点就在加了注解的方法上，切点在方法执行前；因此不论是事务的开启还是数据源的切换，我们都需要关注AOP是如何对其进行改造的。

        在跳转进方法后进入了CglibAopProxy，入参为代理类、方法签名、方法实参和代理方法，重点是在连接点中获取方法对应的注解，再去ProxyFactory获取注解对应的拦截器，返回一个拦截器链列表；当拦截器链不为空时，就会将代理对象、被代理对象、被代理方法、方法入参、被代理类、拦截器链、代理方法传入代理方法执行器并执行。

//获取被代理原对象，也就是单例Bean
target = targetSource.getTarget();
Class targetClass = target != null ? target.getClass() : null;

//根据方法签名和类获取拦截器链
List