记一次多数据源事务不生效事件

1. 第一阶段无头乱撞

2. 第二阶段 查看源码

2.1 跟踪发现

1. TransactionAspectSupport.invokeWithinTransaction方法中final PlatformTransactionManager tm变量持有的数据源和mapper的数据源不一致
2. 结论：开启的事务所用的数据源和sql真正执行的数据源不是一个对象，则导致事务不生效

3. 查看多数据源实现

1. 发现前人自定义一个数据源，并使用CommandLineRunner形式将动态数据源重新注入到spring中，导致mapper使用的是新的，而PlatformTransactionManager的bean中的数据源是之前旧的，所以PlatformTransactionManager 开启事务使用旧数据源，mapper使用新的。

4. 解决

将新的动态数据源注入到spring时直接更新PlatformTransactionManager 中持有的数据源，则完成

		DynamicDataSource bean1 = beanFactory.getBean(DynamicDataSource.class);
		logger.info("Dynamic DataSource Registry");
		DataSourceTransactionManager bean = beanFactory.getBean(DataSourceTransactionManager.class);
		bean.setDataSource(bean1);

5. 总结

• 还是得知道如何看源码，并保持清醒的头脑。
• 比如事务不生效第一反应查询常见情况：

1. public
2. 异常类型及是否没有throw到切面
3. 内部访问
4. 多线程
5. 数据库本身不支持事务等

• 直接查看TransactionInterceptor方法发现，异常正常抛出并且执行了rollback方法，则说明正常流程springboot已经完成
• 这时就应该想到两个connection不是一个connection
• 再往上联想项目使用了多数据源，是否是多数据源的原因，debug发现的确是没使用一个数据源的原因
• 这是查看多数据源实现，发现居然使用CommandLineRunner方法注入多数据源，这个方法是springboot启动最后调用，也就导致了覆盖的dataSource之前的操作并不能控制。
• 总结一句话，自行覆盖注入bean时应该联想到之前的bean之前的引用是否更新