@DS(“XXX”) + @Transactional > table not exist?

今年年初项目引入了 dynamic-datasource ，用于满足业务联动下的多个数据源之间的CRUD。然而在使用的过程中发现，只要在方法上 或者类上 存在这个组合@DS(“XXX”) + @Transactional， 业务流程就会卡住并抛出 XXX table not exist的异常， 移除@Transactional 之后，业务正常进行。 但是这样带来了巨大的隐患，即：出现异常无法回滚。 然鹅，因为项目周期短，节奏快，时间紧，一直没有时间去处理这块的东西。 这个问题的关键在于事务

spring 的事务背后是啥？怎么弄？

这里不赘述事务的定义， 从流程上，非常表面的来看，开启一个spring 的事务就是一个从既定数据源获取不设置自动提交的数据库链接。 流程复盘一下,重点在前4步：

  1. 从DataSource 中获取链接(connection)
  2. 不设置自动提交 ；
  3. 缓存该链接；
  4. 执行业务SQL，但是会从当前线程中获取缓存下来的链接
  5. 判断是否设置了自动提交；
  6. 执行对应的sql；
  7. …

这意味着，当某个业务逻辑中，需要操作其他数据源会有问题，比如

@Transactional 
    public void a() {
			this.b();
	}
    @DS("b-source")
    public void b() {
			// 数据库操作 CRUD
	}

因为当前事务背后的数据库链接并非b-source，这种写法也并不能正常切换到b-source 数据源中。所以我们需要手动指定Spring事务传播属性 propagation; 结合事务的流程，上面的代码我们改成这样:

@Transactional 
    public void a() {
           // a-source 数据源中的各种逻辑操作
			this.b();
	}
    @DS("b-source")
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void b() {
			// 数据库操作 CRUD
	}

回滚属性可以自己定义，这里不再补充。 现在上面这段代码的意思就是执行到b时，重新创建一个事务，完成数据源切换。执行b-source 数据源中的所有crud 操作。虽然它能正常工作了，但是这样也增加了代码的复杂度。

有没有其他方式？

当然有，目前我们项目使用了 Sharding-JDBC 完善对多数据源的支持。
传送门 ： Sharding-JDBC官网 一份配置好的文件, 就可以避开以上遇到的问题,框架切换基本能做到无感切换。 但是作为一个新框架，shardingJDBC 在SQL 语法的支持上，有一些欠缺，具体可以去看官网。 这里重点提一下 关键字的问题，如果我们数据库建表时某些字段与shardingJDBC 的关键字有冲突(比如某字段名叫 ‘json’)，则无法正常执行SQL。 关于shardingJDBC 的后续。用了一段时间之后再记录