昨天的分析痛快淋漓，环环相扣，分享后好评如潮。然而内心却有隐隐疑虑，不知从何而来。本没有计划再写续集，然而一觉醒来，已然恍然大悟。我们边看RIO开幕式，边细细道来。
1. 问题由来
昨日我们庖丁解牛，深入DataSourceTransactionManager源码，解开事务与动态数据源切换之谜，然而在代码测试中，我们遗留了一个致命隐患，时而阴阴作痛，让人无眠。
有趣的是，发文后超400UV竟然无人发觉，又或是无留言功能的弊端？哈哈
在系列I中，我们最终实现了在一个事务方法中，支持动态切换，访问多个数据源，并且似乎最终事务也实现了提交，会滚等。
但，我们在调试中碰到了一个问题，却始终隐隐困扰，如下。
事务回滚
系列I中，我们在第一个数据库操作后，进行回滚，一切正常。
但，当我们把异常抛出放到第二个数据库操作后：
可以看出，日志还有一条数据打出来。
数据库中也可以看出，db1回滚了，但db2没有回滚！
2. 原因解析
其实，昨天系列1中我们隐隐不安的原因，也正是我们剖析源代码，并且日志也可以看出，我们使用的是DataSourceTransactionManager事务管理器。
而常识告诉我们，DataSourceTransactionManager只能管理一个数据源的事务，请问如何能管理多个数据库呢？？
另外，上边的无法完全会滚也再次证明我们的观点。
可以看出，DataSourceTransactionManager始终只是管理着第一个数据源，所以才有当第一个操作执行完抛出异常，db1可以回滚。但是，当两个操作都执行完后，再抛出异常，只有上边图文中的db1回滚，db2没有回滚。
现在真相大白！
另外，据此，我们继续推论，其实如果在注解事务下，强制修改DAO数据源，一样可以实现访问多个数据库，但同样无法真正支撑事务。
事实也正如此！
3. 解决方案
问题清楚了，请问怎么破？
当然引入分布式中间件了，JTA登场。我们采用轻量级非容器分布式事务中间件：atomikos。
XML配置：
引入分布式事务管理器后，我们再来看一下，代码无须改动。
数据库也正常，db1，db2都有数据插入。
我们来重点看一下两种异常的回滚：
db1,db2也正常，都没有插入。
我们看一下关键的异常2回滚。
日志显示0，正常中。我们再次确认数据库。期望db1，db2都回滚，系列1问题就出在db2没有回滚。
正式搞定分布式事务。
总结
不要放过任何小细节，时刻关注底层实现，了解原理。
好了，周末愉快！
关注公众号：技术极客TechBooster
网友评论