概述

分布式事务是指事务的参与者、支持事务的服务器、资源管理器以及事务管理器分别位于分布系统的不同节点之上，在两个或多个网络计算机资源上访问并且更新数据，将两个或多个网络计算机的数据进行的多次操作作为一个整体进行处理。如不同银行账户之间的转账。

对于在项目中接触到JTA，大部分的原因是因为在项目中需要操作多个数据库，同时，可以保证操作的原子性，保证对多个数据库的操作一致性。

一丶问题由来

昨日我们庖丁解牛，深入DataSourceTransactionManager源码，解开事务与动态数据源切换之谜，然而在代码测试中，我们遗留了一个致命隐患，时而阴阴作痛，让人无眠。

有趣的是，发文后超400UV竟然无人发觉，又或是无留言功能的弊端？哈哈

在系列I中，我们最终实现了在一个事务方法中，支持动态切换，访问多个数据源，并且似乎最终事务也实现了提交，会滚等。

但，我们在调试中碰到了一个问题，却始终隐隐困扰，如下。

事务回滚

系列I中，我们在第一个数据库操作后，进行回滚，一切正常。

但，当我们把异常抛出放到第二个数据库操作后：

可以看出，日志还有一条数据打出来。

数据库中也可以看出，db1回滚了，但db2没有回滚！

二丶 原因解析

其实，昨天系列1中我们隐隐不安的原因，也正是我们剖析源代码，并且日志也可以看出，我们使用的是DataSourceTransactionManager事务管理器。

而常识告诉我们，DataSourceTransactionManager只能管理一个数据源的事务，请问如何能管理多个数据库呢？？

另外，上边的无法完全会滚也再次证明我们的观点。

可以看出，DataSourceTransactionManager始终只是管理着第一个数据源，所以才有当第一个操作执行完抛出异常，db1可以回滚。但是，当两个操作都执行完后，再抛出异常，只有上边图文中的db1回滚，db2没有回滚。

现在真相大白！

另外，据此，我们继续推论，其实如果在注解事务下，强制修改DAO数据源，一样可以实现访问多个数据库，但同样无法真正支撑事务。

事实也正如此！

三丶 解决方案

问题清楚了，请问怎么破？

当然引入分布式中间件了，JTA登场。我们采用轻量级非容器分布式事务中间件：atomikos。

XML配置：

引入分布式事务管理器后，我们再来看一下，代码无须改动。

数据库也正常，db1，db2都有数据插入。

我们来重点看一下两种异常的回滚：

db1,db2也正常，都没有插入。

我们看一下关键的异常2回滚。

日志显示0，正常中。我们再次确认数据库。期望db1，db2都回滚，系列1问题就出在db2没有回滚。

正式搞定分布式事务。

总结

以上是对Spring分布式事务，分享给大家，希望大家可以了解什么是Spring分布式事务。觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持。（吹一波，233~~）