spring事務管理器設計思想（二）

上文見《spring事務管理器設計思想（一）》 

對于第二個問題，涉及到事務的傳播級別，定義如下：

PROPAGATION_REQUIRED-- 如果當前沒有事務，就新建一個事務。這是最常見的選擇。 
PROPAGATION_SUPPORTS-- 如果當前沒有事務，就以非事務方式執(zhí)行。 
PROPAGATION_MANDATORY-- 如果當前沒有事務，就拋出異常。 
PROPAGATION_REQUIRES_NEW--新建事務，如果當前存在事務，把當前事務掛起。 
PROPAGATION_NOT_SUPPORTED--以非事務方式執(zhí)行操作，如果當前存在事務，就把當前事務掛起。 
PROPAGATION_NEVER--以非事務方式執(zhí)行，如果當前存在事務，則拋出異常。 

在開啟事務之前，正常情況下需要做兩個事情

一：獲取當前事務上下文信息

二：獲取將要開啟事務的傳播屬性

根據以上兩個信息，來判斷程序的處理方式，具體方式如下：

而處理流程則是如下：

其中上圖標中英文簡稱對應的事務傳播屬性如下：

RE：               PROPAGATION_REQUIRED-- 如果當前沒有事務，就新建一個事務。這是最常見的選擇。 

SPT                PROPAGATION_SUPPORTS-- 如果當前沒有事務，就以非事務方式執(zhí)行。 
MA：              PROPAGATION_MANDATORY-- 如果當前沒有事務，就拋出異常。 
RE_NEW：      PROPAGATION_REQUIRES_NEW--新建事務，如果當前存在事務，把當前事務掛起。 
NOT_SPT:      PROPAGATION_NOT_SUPPORTED--以非事務方式執(zhí)行操作，如果當前存在事務，就把當前事務掛起。 
NEVER:          PROPAGATION_NEVER--以非事務方式執(zhí)行，如果當前存在事務，則拋出異常。 

通過上面發(fā)現，只有新創(chuàng)建資源的時候，才會開啟事務，在其他的情況下，只需要返回事務狀態(tài)信息就可以了。其實這個狀態(tài)信息，就是事務的上下文信息。

事務上下文

通過上面的分析，每次啟動事務的時候，都會判斷當前是否存在事務，要么拋出異常，否則都會創(chuàng)新事務上下文，但是對于數據源的處理方式則是不一樣的，這個要根據當前事務傳播屬性和新的事務傳播屬性共同決定。

事務上下文信息到底是什么，這個完全是可以自定義的，在spring中，主要是表現為TransactionStatus，也就是事務狀態(tài)信息。里面保存了事務相關的信息，

//事務對象信息，使用普通數據源的話，是DataSourceTransactionObject對象，保存//了事務對應的連接信息

private final Object transaction;

//是否是新開啟的事務信息，只有調用了開啟事務的方法，這個才為true

private final boolean newTransaction;

//這個是事務同步器，不是事務要關心的，spring在事務提交之前或者之后座的hook

private final boolean newSynchronization;

//是否是只讀事務

private final boolean readOnly;

//日志debug信息，完全沒有放在這里

private final boolean debug;

//掛起的事務信息，如果沒有，則為空

private final Object suspendedResources;

通過事務狀態(tài)信息，就可以完全知道當前事務的所有信息，包括事務的對應的數據源連接信息，是否是新創(chuàng)建的事務，是否是只讀事務，以及之前掛起的事務信息。這些對事務管理器起來說，都是必須的信息。但是個人覺得也存在一些問題，首先spring這個事務狀態(tài)信息有兩個使用者，一個是spring本身事務管理器使用，另外一個是應用程序接口。對應用程序接口暴露出來的狀態(tài)信息以及內部使用的事務上下文信息應該隔離出來，避免應用程序人為的修改了事務上下文的屬性信息。當然，可以用過接口的方式進行避免，但是如果知道實現原理的話，完全可以通過強制轉化為實現對象，從而破壞事務其他的信息導致程序異常。當然，正常情況下不太可能有人會如此無聊。 

 從上面的分析來看，spring的事務管理器（這里都特指DataSourceTransactionManager）主要的工作流程就是創(chuàng)建事務信息，綁定數據源，獲取數據庫連接，提交活回滾事務，釋放數據庫連接，解綁數據源。其實整個事務管理器做的事情無非就是這些。讓應用者更關注業(yè)務邏輯，而不是復雜的事務管理。

 DataSourceTransactionManager事務管理器本身實現了ResouceManager的功能，就是返回對應的其注冊的datasrouce。這是一種一對一的映射關系，也就是說一個事務管理器只能注冊一個數據源，不支持多數據源的管理。一旦事務管理器開啟事務，就和具體的數據源綁定了，你只能通過其對應的數據源獲取數據庫連接。所以在事務上下文里面操作多個數據庫，是不可能的。同時也只支持單一物理數據源，也就是說一個數據源只能返回同一個數據庫連接，不支持在同一個事務里面通過同一個邏輯數據源跨越多個物理庫操作。下面的操作想通過ProxyDataSource切換實際的數據源的方式無法實現的。

for(String dbName : dbNames){

             DataSourceContextHolder.set(“dbName”);

             doSomeThing();

            DataSourceContextHolder.clear();

}

想要支持跨庫的事務操作，可以通過以下幾種方式操作：

1 使用JtaTransactionManager，通過jta服務提供商來實現跨庫事務

2 改寫ProxyDataSource，通過返回其自己實現的Connection來實現跨庫的事務。簡單的說，返回一個邏輯的Connection，這個connection本身持有多個物理connection

3 自己實現TransactionManager，可以注冊多個資源管理器，自己對多個數據源進行管理。

事務上下文的擴展

正常情通過況下，事務上下文信息都是保存在內存之中，相當于只能夠支持單個jvm。可以想象一下，假設事務管理器把事務上下文信息持久化，并且通過遠程調用的方式，把事務上下文信息傳遞給另外一個jvm，通過這樣的設計思想，可以支持跨jvm間的事務一致性，也就是我們所說的分布式系統(tǒng)的事務。當然，這只是一中簡單的想法，具體的實現會相當復雜，需要考慮點也有很多。