昨天的分析痛快淋漓，環環相扣，分享後好評如潮。然而內心卻有隱隱疑慮，不知從何而來。本沒有計劃再寫續集，然而一覺醒來，已然恍然大悟。

我們邊看RIO開幕式，邊細細道來。

1. 問題由來

昨日我們庖丁解牛，深入DataSourceTransactionManager原始碼，解開事務與動態資料來源切換之謎，然而在程式碼測試中，我們遺留了一個致命隱患，

時而陰陰作痛，讓人無眠。有趣的是，發文後超400UV竟然無人發覺，又或是無留言功能的弊端？哈哈在系列I中，我們最終實現了在一個事務方法中，支援動態切換，訪問多個數據源，並且似乎最終事務也實現了提交，會滾等。但，我們在除錯中

碰到了一個問題，卻始終隱隱困擾，如下。

系列I中，我們在第一個資料庫操作後，進行回滾，一切正常。但，當我們把異常丟擲放到第二個資料庫操作後：

可以看出，日誌還有一條資料打出來。

資料庫中也可以看出，db1回滾了，但db2沒有回滾！

2. 原因解析

其實，昨天系列1中我們隱隱不安的原因，也正是我們剖析原始碼，並且日誌也可以看出，我們使用的是DataSourceTransactionManager

事務管理器。而常識告訴我們，DataSourceTransactionManager只能管理一個數據源的事務，請問如何能管理多個數據庫呢？？另外，

上邊的無法完全會滾也再次證明我們的觀點。可以看出，DataSourceTransactionManager始終只是管理著第一個資料來源，所以才有當第

一個操作執行完丟擲異常，db1可以回滾。但是，當兩個操作都執行完後，再丟擲異常，只有上邊圖文中的db1回滾，db2沒有回滾。現在真相大白！另外，據此，我們繼續推論，其實如果在註解事務下，強制修改DAO資料來源，一樣可以實現訪問多個數據庫，但同樣無法真正支撐事務。

事實也正如此！

3. 解決方案

問題清楚了，請問怎麼破？當然引入分散式中介軟體了，JTA登場。我們採用輕量級非容器分散式事務中介軟體：atomikos。
XML配置：
引入分散式事務管理器後，我們再來看一下，程式碼無須改動。

正式搞定分散式事務。

總結：