Spring框架之事務原始碼完全解析

 

事務的定義及特性：

       事務是併發控制的單元，是使用者定義的一個操作序列。這些操作要麼都做，要麼都不做，是一個不可分割的工作單位。通過事務將邏輯相關的一組操作繫結在一起，以便伺服器保持資料的完整性。事務通常是以begin transaction開始，以commit或rollback結束。commint表示提交，即提交事務的所有操作。具體地說就是將事務中所有對資料的更新寫回到磁碟上的物理資料庫中去，事務正常結束。rollback表示回滾，即在事務執行的過程中發生了某種故障，事務不能繼續進行，系統將事務中對資料庫的所有已完成的操作全部撤消，滾回到事務開始的狀態。

       事務的特性：

       原子性（Atomic）對資料的修改要麼全部執行，要麼全部不執行。

       一致性（Consistent）在事務執行前後，資料狀態保持一致性。

       隔離性（Isolated）一個事務的處理不能影響另一個事務的處理。

       持續性（Durable）事務處理結束，其效果在資料庫中持久化。

 

Java事務的三種類型

       JDBC事務、JTA（Java Transaction API）事務、容器事務。

（1）JDBC事務

       JDBC 事務是用 Connection 物件控制的。JDBC Connection 介面（ java.sql.Connection ）提供了兩種事務模式：自動提交和手工提交。 java.sql.Connection 提供了以下控制事務的方法：

       public void setAutoCommit(boolean)

       public boolean getAutoCommit()

       public void commit()

       public void rollback()

       使用 JDBC 事務界定時，您可以將多個 SQL 語句結合到一個事務中。JDBC 事務的一個缺點是事務的範圍侷限於一個數據庫連線。一個 JDBC 事務不能跨越多個數據庫。

（2）JTA（Java Transaction API）事務

       JTA是一種高層的，與實現無關的，與協議無關的API，應用程式和應用伺服器可以使用JTA來訪問事務。

       JTA允許應用程式執行分散式事務處理—在兩個或多個網路計算機資源上訪問並且更新資料，這些資料可以分佈在多個數據庫上。JDBC驅動程式的JTA支援極大地增強了資料訪問能力。

        如果計劃用 JTA 界定事務，那麼就需要有一個實現 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 介面的 JDBC 驅動程式。一個實現了這些介面的驅動程式將可以參與 JTA 事務。一個 XADataSource 物件就是一個 XAConnection 物件的工廠。 XAConnection是參與 JTA 事務的 JDBC 連線。

       您將需要用應用伺服器的管理工具設定 XADataSource。從應用伺服器和 JDBC 驅動程式的文件中可以瞭解到相關的指導。

       J2EE應用程式用 JNDI 查詢資料來源。一旦應用程式找到了資料來源物件，它就呼叫 javax.sql.DataSource.getConnection()以獲得到資料庫的連線。

       XA 連線與非 XA 連線不同。XA 連線參與了 JTA 事務。這意味著 XA 連線不支援 JDBC 的自動提交功能。同時，應用程式一定不要對 XA 連線呼叫 java.sql.Connection.commit()或者 java.sql.Connection.rollback()。相反，應用程式應該使用 UserTransaction.begin()、UserTransaction.commit() 和 serTransaction.rollback()。.

（3）容器事務

        容器事務主要是J2EE應用伺服器提供的，容器事務大多是基於JTA完成，這是一個基於JNDI的，相當複雜的API實現。相對編碼實現JTA事務管理， 我們可以通過EJB容器提供的容器事務管理機制（CMT）完成同一個功能，這項功能由J2EE應用伺服器提供。這使得我們可以簡單的指定將哪個方法加入事 務，一旦指定，容器將負責事務管理任務。通過這種方式我們可以將事務程式碼排除在邏輯編碼之外，同時將所有困難交給J2EE容器去解決。使用EJB CMT的另外一個好處就是程式設計師無需關心JTA API的編碼，不過，理論上我們必須使用EJB。

（4）三種Java事務差異

       JDBC事務控制的侷限性在一個數據庫連線內，但是其使用簡單。

        JTA事務的功能強大，事務可以跨越多個數據庫或多個DAO，使用也比較複雜。

       容器事務，主要指的是J2EE應用伺服器提供的事務管理，侷限於EJB應用使用。

（5）應用場景

       Java事務控制是構建J2EE應用不可缺少的一部分，合理選擇應用何種事務對整個應用系統來說至關重要。一般說來，在單個JDBC 連線的情況下可以選擇JDBC事務，在跨多個連線或者資料庫情況下，需要選擇使用JTA事務，如果用到了EJB，則可以考慮使用EJB容器事務。

       下面基於的Spring版本為5.2.4.BUILD-SNAPSHOT原始碼，對Spring事務tx模組中包含的類和介面進行介紹。

 

一、dao

       Spring事務中的dao模組定義了資料庫層的各種異常，主要是dao的支援和異常的轉譯。在這裡簡要介紹Dao設計模式：

       Dao設計模式（Data Access Object），稱為資料訪問物件。它是對於資料庫操作的一種設計方式，把Dao設計為一個通用介面，提供對資料庫進行增、刪、改、查的一系列操作資料庫的抽象方法。通俗來講，就是將資料庫操作都封裝起來。

       面向物件程式設計的核心就是類、物件。資料庫中每一張Table可以看作一個Class，而列就可以看作類中的一些屬性。這是面向物件的基本思想，通過這種思想我們需要提供的Class就相當於Table的數量。而每次對資料庫的操作時，根據查詢的Table不同，就會得到不同的Class。

       又因為每個Class中操作增、刪、改、查的方法都大相近庭，這就造成的程式碼的冗餘、所以就出現Dao的設計思想。利用Dao介面提供的抽象方法對資料庫進行操作就大大的降低程式碼重複，間接地可以提高程式的效率、效能等。

       Dao模式的優勢就在於它實現了兩次隔離。

       （1）隔離了資料訪問程式碼和業務邏輯程式碼。業務邏輯程式碼直接呼叫Dao方法即可，完全感覺不到資料庫表的存在。分工明確，資料訪問層程式碼變化不影響業務邏輯程式碼，這符合單一職能原則，降低了耦合性，提高了可複用性。

       （2）隔離了不同資料庫實現。採用面向介面程式設計，如果底層資料庫變化，如由 MySQL 變成 Oracle 只要增加Dao介面的新實現類即可，原有 MySQ 實現不用修改。這符合 "開-閉" 原則。該原則降低了程式碼的耦合性，提高了程式碼擴充套件性和系統的可移植性。

       一個典型的Dao模式主要由以下幾部分組成：

       （1）Dao介面： 把對資料庫的所有操作定義成抽象方法，可以提供多種實現。

       （2）Dao實現類： 針對不同資料庫給出Dao介面定義方法的具體實現。

       （3）實體類：用於存放與傳輸物件資料。

       （4）資料庫連線和關閉工具類： 避免了資料庫連線和關閉程式碼的重複使用，方便修改。

 

01 dao/

1.1  CannotAcquireLockException：執行一個更新獲取相應鎖失敗時丟擲的異常，比如一個"select for update"語句。

1.2  CannotSerializeTransactionException：執行一個序列化模式下的事務失敗丟擲的異常。

1.3  CleanupFailureDataAccessException：在一個數據訪問操作正常結束後我們無法進行清理丟擲的異常。比如，一個JDBC連線在成功被使用後無法關閉。

1.4  ConcurrencyFailureException：併發失敗時丟擲的異常。該異常類需要被子類繼承以指示失敗的型別：樂觀鎖、未能成功獲取鎖等。

1.5  DataAccessException：資料訪問異常類的一個處於根位置的基類。

1.6  DataAccessResourceFailureException：資源完全失效時丟擲的資料訪問異常。比如，我們使用JDBC無法連線到一個數據庫中。

1.7  DataIntegrityViolationException：當嘗試插入或者更新資料時違反了完整性約束時丟擲的異常。

1.8  DataRetrievalFailureException：檢索資料失敗時丟擲的異常，比如，通過一個已知識別符號查詢指定的資料。該異常類會被物件關係對映工具或者DAO實現類丟擲。

1.9  DeadlockLoserDataAccessException：當前程序發生死鎖，它的事務需要回滾時丟擲的一般異常。

1.10  DuplicateKeyException：當嘗試插入或者更新資料時違反了主鍵或者唯一性約束丟擲的異常。

1.11  EmptyResultDataAccessException：當期望返回的結果至少包含一行資料（或者元素），但實際只有0個時丟擲的異常。

1.12  IncorrectResultSizeDataAccessException：當返回的結果大小和期望的不一致時丟擲的異常，比如，期望得到1行資料但是返回的0或者多於1行的資料。

1.13  IncorrectUpdateSemanticsDataAccessException：當在執行更新操作時發生了一些計劃外的事情，但是事務並沒有要回滾時丟擲的資料讀取異常。比如，當我們想要更新資料庫管理系統中的1行資料時，但是卻實際更新了3行。

1.14  InvalidDataAccessApiUsageException：對API錯誤使用丟擲的異常，例如未能 “編譯”需要在執行前編譯的查詢物件。

1.15  InvalidDataAccessResourceUsageException：當我們不正確使用一個數據讀取資源時丟擲異常。比如，在使用關係資料庫管理系統指定了錯誤的SQl語句。

1.16  NonTransientDataAccessException：一種非暫態的資料訪問異常，因為同一操作的重試仍然會失敗還會引發該異常，除非引發異常的原因排除。

1.17  NonTransientDataAccessResourceException：資源完全失效丟擲的資料訪問異常，而且這種失效是永久的。

1.18  OptimisticLockingFailureException：樂觀鎖衝突丟擲的異常。物件關係對映工具或者個性化的DAO實現類會丟擲該異常。樂觀鎖失效通常不是由資料庫自身檢測出來。

1.19  PermissionDeniedDataAccessException：當一個潛在的資源被拒絕訪問一個指定的元素，比如一個指定的資料庫表時丟擲的異常。

1.20  PessimisticLockingFailureException：悲觀鎖衝突引發的異常。當發生這種資料庫錯誤的時候，由Spring的SQLException轉換機制丟擲。

1.21  QueryTimeoutException：查詢超時丟擲的異常。根據使用的資料庫API可能會有不同的原因引發該異常，最有可能的就是一個執行中的查詢操作完成前被資料庫中斷或者中止了。

1.22  RecoverableDataAccessException：如果應用執行一些恢復步驟、重試整個事務或者如果是分散式事務，事務分開，先前一個失敗的操作可能可以成功的丟擲的資料訪問異常。

1.23  TransientDataAccessException：表示一些暫態的資料訪問異常，當操作在無干擾的情況下重試，先前失敗的操作很可能會成功。

1.24  TransientDataAccessResourceException：當資源暫時性失效、操作還可以重試時丟擲的資料訪問異常。

1.25  TypeMismatchDataAccessException：Java型別和資料庫類別不匹配時丟擲的異常。比如，嘗試將錯誤型別的物件設定到一個關係資料庫管理系統的列上。

1.26  UncategorizedDataAccessException：無法歸類的異常，比如，JDBC發生了一個SQLException，但是我們無法將其精確定位到更具體的異常。

 

02 dao/annotation

2.1  PersistenceExceptionTranslationAdvisor：是一個spring aop的異常轉譯類，它應用到respository層或者dao層。它基於給定的PersistenceExceptionTranslator來將本地持久化異常轉換為spring的DataAccessException族。

2.2  PersistenceExceptionTranslationPostProcessor：自動將標示為@repository的bean的持久化異常進行轉譯。它增加一個PersistenceExceptionTranslationAdvisor來代理相應的已經存在的aop代理或者實現了目標介面的新產生的代理。它將本地資源異常轉換為spring的DataAccessException及其子類上。

 

03 dao/support

3.1  DaoSupport：DAOs的通用基類，定義了DAO初始化的模板方法。會被Spring的DAO支援類所繼承，比如JdbcDaoSupport， JdoDaoSupport等等。

3.2  DataAccessUtils：DAO實現類的各種實用方法。適用於任何資料訪問技術。提供的方法主要用於從給定的集合中返回結果物件，如果找到0個或者多個則丟擲相應的異常。

3.3  PersistenceExceptionTranslator：spring整合其它資料獲取技術（如jpa、toplink、jdo、hibernate等）丟擲執行時異常的介面。

3.4  ChainedPersistenceExceptionTranslator：PersistenceExceptionTranslator介面的實現類，支援鏈技術，允許按順序新增PersistenceExceptionTranslator例項。

3.5  PersistenceExceptionTranslationInterceptor：一個aop 方法攔截器（MethodInterceptor）。提供基於PersistenceExceptionTranslator的異常轉換，它是PersistenceExceptionTranslator的代理，將執行時丟擲的異常轉換為spring 的DataAccessException族。

 

二、jca

       JCA （J2EE 聯結器架構，Java Connector Architecture）是對J2EE標準集的重要補充。因為它注重的是將Java程式連線到非Java程式和軟體包中介軟體的開發。聯結器特指基於Java聯結器架構的源介面卡，其在J2EE 1.3規範中被定義。JCA聯結器同時提供了一個重要的能力，即它使J2EE應用伺服器能夠整合任何使用JCA介面卡的企業資訊系統（EIS），大大簡化了異構系統的整合。有了JCA，企業只要購買一個基於JCA規範的介面卡，就可以將企業應用部署到J2EE伺服器上，這樣不用編寫任何程式碼就可以實現與J2EE應用伺服器的整合。JCA還提供了一個應用伺服器和EIS連線的標準Java解決方案。

       JCA的目標在於企業應用程式整合方面，它提供的標準化體系結構讓J2EE元件能夠對異構EIS進行“即插即用”的訪問，其中包括ERP、事務處理、老式資料庫系統等。

JCA定義了一套標準的介面SPI，用於讓聯結器把相容的應用程式伺服器無縫的整合起來。同時，定義的另一套標準介面CCI允許客戶（或者應用程式伺服器的應用程式主機）用一種統一的方法使用聯結器。這樣，聯結器對於跨應用程式伺服器就是可移植的，而客戶程式成為很輕便的聯結器。

       （1）SPI（Service provider interfaces）是聯結器提供者（connector provider）必須實現的介面。 這些介面組成了一個能被部署在J2EE應用伺服器上的資源介面卡（resource adapter）。 在這種情況下，由伺服器來管理連線池（connection pooling）、事務和安全（託管模式（managed mode））。 應用伺服器還負責管理客戶端應用程式之外所擁有的配置。聯結器（connector）同樣能在脫離應用伺服器的情況下使用；在這種情況下，應用程式必須直接對它進行配置（非託管模式（non-managed mode））。

       （2）CCI （Common Client Interface）是應用程式用來與聯結器互動並與EIS通訊的介面。同樣還為本地事務劃界提供了API。

       Spring對CCI的支援，目的是為了提供以典型的Spring方式來訪問CCI聯結器的類，並有效地使用Spring的通用資源和事務管理工具。

       注意： 聯結器的客戶端不必總是使用CCI。 某些聯結器暴露它們自己的API，只提供JCA資源介面卡（resource adapter） 以使用J2EE容器的某些系統契約（system contracts）（連線池（connection pooling），全域性事務（global transactions），安全（security））。 Spring並沒有為這類聯結器特有（connector-specific）的API提供特殊的支援。

 

01 jca/cci/

1.1  CannotCreateRecordException：因為聯結器內部原因無法建立一個CCI  Record丟擲的異常。

1.2  CannotGetCciConnectionException：當我們使用CCI （Common Client Interface）無法連線到一個EIS（企業資訊系統）丟擲的致命異常。

1.3  CciOperationNotSupportedException：當聯結器不支援一個指定的CCI操作時丟擲的異常。

1.4  InvalidResultSetAccessException：以無效的方式訪問一個結果集時丟擲的異常。比如指定一個無效的結果集的列索引或者名字時發生。

1.5  RecordTypeNotSupportedException：當聯結器不支援CCI  Record型別，導致建立一個CCI  Record失敗時丟擲的異常。

jca/cci/connection

1.6  CciLocalTransactionManager ：繼承自PlatformTransactionManager，為一個CCI 連線工廠管理本地事務。將來自指定ConnectionFactory的CCI 連線繫結到執行緒中。

       應用程式碼需要通過ConnectionFactoryUtils類的getConnection(ConnectionFactory)方法來獲取CCI連線，而不是用標準的Java EE-style  ConnectionFactory類的getConnection()方法。

1.7  ConnectionFactoryUtils：幫助類，提供了從一個javax.resource.cci.ConnectionFactory中獲取CCI 連線的靜態方法。為Spring管理事務連線提供了專門的支援，比如通過CciLocalTransactionManager或JtaTransactionManager進行管理。

       該類會被CciTemplate、Spring的CCI操作物件和CciLocalTransactionManager內部使用，也可以直接在應用程式碼中使用。

1.8  ConnectionHolder：封裝了一個CCI 連線的資源控制代碼。CciLocalTransactionManager為一個給定的ConnectionFactory繫結該類的例項到執行緒中。

1.9  ConnectionSpecConnectionFactoryAdapter：一個目標CCI  ConnectionFactory介面卡，將給定的ConnectionSpec應用到每一個標準的getConnection()方法中，也就是說，在目標上呼叫getConnection(ConnectionSpec)方法。其他所有的方法簡單的委託給目標ConnectionFactory相應的方法。

1.10  DelegatingConnectionFactory：CCI ConnectionFactory介面的實現類，將所有的呼叫委託給給定的目標ConnectionFactory。

     該類最好被子類繼承，子類可以覆蓋這些方法（比如getConnection()），而不是簡單的委託給目標ConnectionFactory。

1.11  NotSupportedRecordFactory：CCI RecordFactory介面的實現類，總是丟擲NotSupportedException異常。

       作為RecordFactory引數的佔位符使用（比如，由RecordCreator回撥定義），尤其是當聯結器的ConnectionFactory.getRecordFactory()實現丟擲NotSupportedException異常，而不是從 RecordFactory的方法中丟擲異常。

1.12  SingleConnectionFactory：一個CCI ConnectionFactory介面卡，對於所有的getConnection呼叫返回相同的連線，忽略對Connection.close()的呼叫。

       用於測試或者單機的環境中，對不同的CciTemplate呼叫，使用相同的連線，沒有池連線工廠，同時也跨越任意數量的事務。

1.13  TransactionAwareConnectionFactoryProxy：代理一個目標CCI ConnectionFactory，增加了對Spring管理事務的感知。同Java EE server提供的事務JNDI  ConnectionFactory相似。

jca/cci/core/   

1.14  CciOperations：指定在企業資訊系統（EIS）上的一套基本的操作的介面。被CciTemplate實現。不常用，但是可以用來增強測試，因為它可以方便的進行mocked or stubbed。

       Mock：我們可以在不實現具體物件的情況下，即在沒有某個類的例項的情況下對該物件的行為進行模擬。這一特徵對於面向介面的程式設計非常有用。因為介面的呼叫者可以在沒有介面的具體實現的情況下使用介面，也就是說呼叫者可以先於介面的實現者行動。

       它的主要工作是模擬出一個被模擬物件的例項，其中包括模擬對該例項的呼叫行為（比如訪問屬性、呼叫方法之類）、模擬方法或屬性訪問的返回值、模擬方法和索引的引數傳遞等等，可以說基本上對於一個物件例項的使用它都可以模擬出來。這樣一來，我們就可以好像真的有一個我們需要的例項存在一樣，正常地使用它，來完成對呼叫者程式碼的開發和測試。

       mock使用easymock等包，在程式程式碼中向被測試程式碼注入“依賴部分”，通過程式碼可程式設計的方式模擬出函式呼叫返回的結果。mock關注行為驗證。細粒度的測試，即程式碼的邏輯，多數情況下用於單元測試。

       stub：是真實物件的一個模擬，比如呼叫者需要一個值，那就讓stub輸出一個值，如果呼叫者需要傳遞一個值給stub，那就在stub中定義一個方法接受該引數。

       但是這與mock的物件存在本質的區別：stub雖然說也是模擬，但其本質上對真是物件的一個簡單實現，而無論它有多簡單它都是一種實現，它是真實存在的，它裡面包含了我們定義的操作程式碼；反觀mock的物件，它根本是不存在的，哪怕一句的簡單的不能再簡單的程式碼都不存在。

       stub自己寫程式碼代替“依賴部分”。它本身就是“依賴部分”的一個簡化實現。stub關注狀態驗證。粗粒度的測試，在某個依賴系統不存在或者還沒實現或者難以測試的情況下使用，例如訪問檔案系統，資料庫連線，遠端協議等。

1.15  CciTemplate：CCI core包和核心類。它簡化了對CCI的使用，幫助避免一些常見的錯誤。它執行核心CCI工作流，這樣應用程式碼只需要提供引數給CCI然後獲取結果。該類執行企業資訊系統（EIS）的查詢和更新操作，捕獲ResourceExceptions異常同時將這些異常轉換成在org.springframework.dao包中定義的通用異常類。

1.16  ConnectionCallback：通用的回撥介面，用於操作一個CCI連線的程式碼。允許使用任意型別和數量的互動，在單個連線上執行任意數量的操作。

1.17  InteractionCallback：通用的回撥介面，用於操作一個CCI互動的程式碼。允許在單個互動上執行任意數量的操作，比如單個的execute呼叫或者使用不同引數多次execute呼叫。

1.18  RecordCreator：回撥介面，用於建立一個CCI Record例項，常常基於passed-in CCI RecordFactory。

1.19  RecordExtractor：回撥介面，用於從一個CCI  Record例項中獲取一個結果物件。

jca/cci/core/support

1.20  CciDaoSupport：基於CCI的資料讀取物件的父類。需要設定一個ConnectionFactory，提供一個CciTemplate。

1.21  CommAreaRecord：CCI  Record介面的實現類，用於COMMAREA，持有一個位元組陣列。

jca/cci/object

1.22  EisOperation：使用CCI API的EIS操作物件的基類。封裝了一個CCI ConnectionFactory 和一個 CCI InteractionSpec。

1.23  MappingCommAreaOperation：EIS操作物件用於訪問COMMAREA records。

1.24  MappingRecordOperation：EIS操作物件，該抽象類的子類必須實現抽象函式createInputRecord(RecordFactory, Object)：從一個物件建立一個input Record。extractOutputData(Record)：轉換一個output Record到一個物件。

1.25  SimpleRecordOperation：EIS操作物件，接受一個passed-in CCI input Record，返回一個相應的CCI output Record。

 

02 jca/context

2.1  BootstrapContextAware：需要通知BootStrapContext的實現類。

2.2  BootstrapContextAwareProcessor：傳遞BootstrapContext到實現了BootStrapContextAware介面的spring bean。它在內部bean factory中自動註冊。

2.3  ResourceAdapterApplicationContext：一個jca ResourceAdapter的applicationContext實現，需要於jca的bootstrapContext一同初始化，最後傳遞到實現了BootstrapContextAware的spring 受管理bean。

2.4  SpringContextResourceAdapter：JCA 1.7 ResourceAdapter介面實現類，載入了一個Spring ApplicationContext容器，啟動和停止Spring託管的bean作為ResourceAdapter生命週期的一部分。

 

03 jca/endpoint

3.1  AbstractMessageEndpointFactory：實現了jca 1.5、1.6、1.7版本的javax.resource.spi.endpoint.MessageEndpointFactory介面，它提供了事務管理能力。

3.2  GenericMessageEndpointFactory：實現了抽象方法，對任意型別的訊息監聽物件（javax.jms.MessageListener）或者javax.resource.cci.MessageListener物件提供了事務管理的能力。

3.3  GenericMessageEndpointManager：使用Spring application context對JCA 1.7 訊息端點進行管理的通用的bean。啟用和停止這個端點作為application context容器生命週期的一部分。

 

04 jca/support

4.1  LocalConnectionFactoryBean：建立一個本地JCA連線工廠。

4.2  ResourceAdapterFactoryBean：使用BootStrapContext啟動一個jca 1.5指定的ResouceAdapter。

4.3  SimpleBootstrapContext：BootstrapContext提供一種機制，這種機制將一個Bootstrap的上下文傳遞到一個資源介面卡例項。

 

05 jca/work

5.1  DelegatingWork：簡單的任務介面卡，委託給一個給定的Runnable。

5.2  SimpleTaskWorkManager：JCA 1.7 javax.resource.spi.work.WorkManager介面的簡單實現，委託給一個Spring TaskExecutor。提供了簡單的任務執行，但是不支援一個JCA ExecutionContext（比如，不支援匯入的事務）。

5.3  WorkManagerTaskExecutor：TaskExecutor介面實現類，代表一個JCA 1.7 WorkManager，實現了WorkManager介面。

 

三、transaction

01 transaction/

1.1  PlatformTransactionManager：事務管理介面，完成對事務的管理和操作，比如開啟事務，提交和回滾事務。通過實現此介面，完成對已經建立的事務進行操作。該介面中提供了三個事務操作方法，具體如下。

       TransactionStatus getTransaction（TransactionDefinition definition）：用於獲取事務狀態資訊。

       void commit（TransactionStatus status）：用於提交事務。

       void rollback（TransactionStatus status）：用於回滾事務。

 

事務三大介面：

       PlatformTransactionManager 事務管理器。

       TransactionDefinition 事務的一些基礎資訊，如超時時間、隔離級別、傳播屬性等。

       TransactionStatus 事務的一些狀態資訊，如是否一個新的事務、是否已被標記為回滾。

1.2  TransactionDefinition：事務定義資訊（配置資訊來自xml配置檔案和註解）。包括事務的隔離級別，事務的傳播特性，事務超時時間，事務只讀特性。它提供了事務相關資訊獲取的方法，其中包括五個操作:

       String getName()：獲取事務物件名稱。

       int getIsolationLevel()：獲取事務的隔離級別。

       int getPropagationBehavior()：獲取事務的傳播行為。

       int getTimeout()：獲取事務的超時時間。

       boolean isReadOnly()：獲取事務是否只讀。

 

事務隔離級別：

        事務四大特性 : ACID  原子性、一致性、隔離性、永續性。隔離性引發併發問題：髒讀、不可重複讀、虛讀。髒讀：一個事務讀取另一個事務未提交資料。不可重複讀：一個事務讀取另一個事務已經提交 update 資料。虛讀：一個事務讀取另一個事務已經提交 insert 資料。事務隔離級別為了解決事務隔離性引發問題，定義了5種隔離級別：

      ISOLATION_DEFAULT 這是一個PlatfromTransactionManager預設的隔離級別，使用資料庫預設的事務隔離級別。另外四個與JDBC的隔離級別相對應。

        ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別，它充許別外一個事務可以看到這個事務未提交的資料。這種隔離級別會產生髒讀，不可重複讀和幻像讀。

        ISOLATION_READ_COMMITTED 保證一個事務修改的資料提交後才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的資料。這種事務隔離級別可以避免髒讀出現，但是可能會出現不可重複讀和幻像讀。

        ISOLATION_REPEATABLE_READ 這種事務隔離級別可以防止髒讀，不可重複讀。但是可能出現幻像讀。它除了保證一個事務不能讀取另一個事務未提交的資料外，還保證了避免下面的情況產生(不可重複讀)。

        ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。除了防止髒讀，不可重複讀外，還避免了幻像讀。

 

事務的傳播行為

        傳播行為解決問題：一個業務層事務呼叫另一個業務層事務，事務之間關係如何處理。事務的傳播行為在jdbc規範中是沒有定義的，jdbc規範只定義了事務的隔離級別。為什麼要有事務的傳播行為，就是為了方便開發實際開發中的問題：業務層方法之間的互相呼叫。

        例如：刪除客戶的同時，也要刪除與客戶相關聯的訂單。這時就會在CustomerService的deleteCustomer方法中呼叫OrderSerivce中的deleteOrder方法。如果訂單刪除失敗了，那麼就不應該刪除客戶，所以這兩個操作必須放到同一個事務中。另一種情況：訂單刪除失敗了，仍然要把客戶刪除，這兩個操作也需要事務。

      傳播行為解決的問題是：一個業務層的事務，呼叫另一個業務層事務，事務之間的關係如何處理。

       在Spring中定義了七中事務傳播行為：

       （1） PROPAGATION_REQUIRED：支援當前事務，如果不存在就新建一個。

        刪除客戶時刪除訂單，處於同一個事務，如果刪除訂單失敗，刪除客戶也要回滾。

       （2） PROPAGATION_SUPPORTS ：支援當前事務，如果不存在，就不使用事務。

        刪除客戶時刪除訂單，如果刪除客戶時沒有開啟事務，那麼刪除訂單也不使用事務。

       （3）PROPAGATION_MANDATORY：支援當前事務，如果不存在，丟擲異常。

        刪除客戶時刪除訂單，如果在刪除訂單時沒開事務，則丟擲異常。

       （4）PROPAGATION_REQUIRES_NEW：如果有事務存在，掛起當前事務，建立一個新的事務。

        生成訂單，傳送通知郵件，通知郵件會建立一個新的事務，如果郵件失敗，不影響訂單生成事務。

       （5）PROPAGATION_NOT_SUPPORTED：以非事務方式執行，如果有事務存在，掛起當前事務。

       （6）PROPAGATION_NEVER：以非事務方式執行，如果有事務存在，丟擲異常。

       （7）PROPAGATION_NESTED  如果當前事務存在，則巢狀事務執行。依賴於 JDBC3.0 提供 SavePoint 技術。

       刪除客戶刪除訂單， 在刪除客戶後，設定SavePoint，執行刪除訂單，刪除訂單和刪除客戶在同一個事務，刪除訂單失敗，事務回滾 SavePoint，由使用者控制是事務提交還是回滾。

1.3  TransactionStatus ：事務的一些狀態資訊，如是否是一個新的事務、是否已被標記為回滾。

       isNewTransaction()：返回當前事務狀態是否是新事務；

       hasSavepoint()：返回當前事務是否有儲存點；

       setRollbackOnly()：設定當前事務應該回滾；

       isRollbackOnly(()：返回當前事務是否應該回滾；

       flush()：用於重新整理底層會話中的修改到資料庫，一般用於重新整理如Hibernate/JPA的會話，可能對如JDBC型別的事務無任何影響；

       isCompleted():當前事務否已經完成。

1.4  CannotCreateTransactionException：使用一個事務API比如JTA（即Java Transaction API），建立不了一個事務時丟擲的異常。

1.5  HeuristicCompletionException：事務協調器試探式的決策導致事務失敗丟擲的異常。

1.6  IllegalTransactionStateException：根據應用的事務傳播行為，當事務的存在或不存在等於非法狀態時引發異常。

1.7  InvalidIsolationLevelException：當指定了一個非法的隔離級別時丟擲的異常，比如，一個事務管理器不支援的隔離級別。

       在標準SQL規範中定義了4個事務隔離級別，不同隔離級別對事務處理不同：

       （1） 未授權讀取 Read Uncommitted：也稱未提交讀。防止更新丟失（對應一級鎖），如果一個事務已經開始寫資料則另外一個數據則不允許同時進行寫操作但允許其他事務讀此行資料。該隔離級別可以通過“排他寫鎖”實現。事務隔離的最低級別，僅可保證不讀取物理損壞的資料。與READ COMMITTED 隔離級相反，它允許讀取已經被其它使用者修改但尚未提交確定的。

       （2）授權讀取 Read Committed：也稱提交讀。“未授權讀取”之上防止髒讀取（對應二級鎖）。這可以通過“瞬間共享讀鎖”和“排他寫鎖”實現，讀取資料的事務允許其他事務繼續訪問該行資料，但是未提交寫事務將會禁止其他事務訪問該行。SQL Server 預設的級別。在此隔離級下，SELECT 命令不會返回尚未提交（Committed） 的資料，也不能返回髒資料。

       （3）可重複讀取 Repeatable Read：“授權讀取”之上防止不可重複讀取（對應三級鎖）。但是有時可能出現幻影資料，這可以通過“共享讀鎖”和“排他寫鎖”實現，讀取資料事務將會禁止寫事務（但允許讀事務），寫事務則禁止任何其他事務。在此隔離級下，用SELECT 命令讀取的資料在整個命令執行過程中不會被更改。此選項會影響系統的效能，非必要情況最好不用此隔離級。三級封鎖協議並不能阻止幻讀，修改的不能再被讀取，但是新增（刪除）的記錄數可以統計。

       （4）序列 Serializable：也稱可序列讀（對應兩段鎖）。提供嚴格的事務隔離，它要求事務序列化執行，事務只能一個接著一個地執行，但不能併發執行。如果僅僅通過 “行級鎖”是無法實現事務序列化的，必須通過其他機制保證新插入的資料不會被剛執行查詢操作事務訪問到。事務隔離的最高級別，事務之間完全隔離。如果事務在可序列讀隔離級別上執行，則可以保證任何併發重疊事務均是序列的。

1.8  InvalidTimeoutException：指定一個非法的timeout時限丟擲的異常，也就是說指定的時限超出了範圍或者事務管理器不支援時限。

1.9  NestedTransactionNotSupportedException：試圖使用巢狀式事務，但是底層後端不支援巢狀式事務丟擲的異常。

1.10  NoTransactionException：當一個操作依賴於一個現有的事務（比如設定回滾的狀態），但是不存在這個現有的事務時丟擲的異常。該異常表示非法使用事務API的情況。

1.11  ReactiveTransaction：表示一個還在發展中的反應式事務。現在是拓展自TransactionExecutio的標記介面，在將來的版本中可能會進一步包含方法。

       事務程式碼能使用該類獲取狀態資訊，以程式設計方式請求一個回滾（而不是丟擲一個異常而引發一個完全的回滾）。

1.12  ReactiveTransactionManager：在Spring響應式事務架構中這個一個核心介面。應用可以直接使用該介面，但它並不是主要做API使用：通常，應用通過AOP使用事務操作或者宣告式事務劃分。

1.13  SavepointManager：以通用的方式管理事務儲存點（savepoint）。會被TransactionStatus繼承，為一個指定的事務暴露儲存點管理器。

1.14  StaticTransactionDefinition：一個靜態的、不可更改的transaction definition。

1.15  TransactionException：所有事務異常類的父類。

1.16  TransactionExecution：用來表示事務的當前狀態，作為TransactionStatus和ReactiveTransaction的父介面。

1.17  TransactionManager：Spring事務管理器實現類的標記介面，傳統的或者反應式的。

       Marker Interface標記介面有時也叫標籤介面（Tag interface），即介面不包含任何方法。

        標記介面是電腦科學中的一種設計思路。程式語言本身不支援為類維護元資料。而標記介面則彌補了這個功能上的缺失：一個類實現某個沒有任何方法的標記介面，實際上標記介面從某種意義上說就成為了這個類的元資料之一。執行時，通過程式語言的反射機制，我們就可以在程式碼裡拿到這種元資料。

       以Serializable介面為例。一個類實現了這個介面，說明它可以被序列化。因此，我們實際上通過Serializable這個介面，給該類標記了“可被序列化”的元資料，打上了“可被序列化”的標籤。這也是標記/標籤介面名字的由來。

 

       Spring提供了許多內建事務管理器實現：

       （1）DataSourceTransactionManager：位於org.springframework.jdbc.datasource包中，資料來源事務管理器，提供對單個javax.sql.DataSource事務管理，用於Spring JDBC抽象框架、iBATIS或MyBatis框架的事務管理；

       （2）JdoTransactionManager：位於org.springframework.orm.jdo包中，提供對單個javax.jdo.PersistenceManagerFactory事務管理，用於整合JDO框架時的事務管理；

       （3）JpaTransactionManager：位於org.springframework.orm.jpa包中，提供對單個javax.persistence.EntityManagerFactory事務支援，用於整合JPA實現框架時的事務管理；

       （4）HibernateTransactionManager：位於org.springframework.orm.hibernate3包中，提供對單個org.hibernate.SessionFactory事務支援，用於整合Hibernate框架時的事務管理；該事務管理器只支援Hibernate3+版本，且Spring3.0+版本只支援Hibernate 3.2+版本；

       （5）JtaTransactionManager：位於org.springframework.transaction.jta包中，提供對分散式事務管理的支援，並將事務管理委託給Java EE應用伺服器事務管理器；

OC4JjtaTransactionManager：位於org.springframework.transaction.jta包中，Spring提供的對OC4J10.1.3+應用伺服器事務管理器的介面卡，此介面卡用於對應用伺服器提供的高階事務的支援；

       （6）WebSphereUowTransactionManager：位於org.springframework.transaction.jta包中，Spring提供的對WebSphere 6.0+應用伺服器事務管理器的介面卡，此介面卡用於對應用伺服器提供的高階事務的支援；

       （7）WebLogicJtaTransactionManager：位於org.springframework.transaction.jta包中，Spring提供的對WebLogic 8.1+應用伺服器事務管理器的介面卡，此介面卡用於對應用伺服器提供的高階事務的支援。

1.18  TransactionSuspensionNotSupportedException：試圖掛起一個事務，但是底層後臺不支援事務的掛起時丟擲的異常。

1.19  TransactionSystemException：當一個事務系統發生故障時丟擲的異常，比如在提交或者回滾時。

1.20  TransactionTimedOutException：當一個事務超時了丟擲的異常。

1.21  TransactionUsageException：不適當的使用Spring事務API丟擲的異常。

1.22  UnexpectedRollbackException：嘗試提交一個事務，但是引發了一個意料之外的回滾丟擲的異常。

 

02 transaction/annotation

2.1  AbstractTransactionManagementConfiguration：配置類（@Configuration）的抽象基類，提供了公共結構用於開啟Spring的註解驅動的事務管理能力。

2.2  AnnotationTransactionAttributeSource：完成建立SpringTransactionAnnotationParser、JtaTransactionAnnotationParser、Ejb3TransactionAnnotationParser物件並新增到解析器列表中，以便後面處理對應註解的工作。

2.3  Ejb3TransactionAnnotationParser：策略實現，用於解析EJB3的TransactionAttribute註解。

2.4  EnableTransactionManagement：開啟Spring的註解驅動事務管理能力，使用在@Configuration類中。

2.5  Isolation：Isolation 列舉類中定義了五個表示隔離級別的值：

       （1）DEFAULT ：這是預設值，表示使用底層資料庫的預設隔離級別。對大部分資料庫而言，通常這值就是： READ_COMMITTED 。

       （2）READ_UNCOMMITTED ：該隔離級別表示一個事務可以讀取另一個事務修改但還沒有提交的資料。該級別不能防止髒讀和不可重複讀，因此很少使用該隔離級別。

       （3） READ_COMMITTED ：該隔離級別表示一個事務只能讀取另一個事務已經提交的資料。該級別可以防止髒讀，這也是大多數情況下的推薦值。

       （4） REPEATABLE_READ ：該隔離級別表示一個事務在整個過程中可以多次重複執行某個查詢，並且每次返回的記錄都相同。即使在多次查詢之間有新增的資料滿足該查詢，這些新增的記錄也會被忽略。該級別可以防止髒讀和不可重複讀。

       （5）SERIALIZABLE ：所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說，該級別可以防止髒讀、不可重複讀以及幻讀。但是這將嚴重影響程式的效能。通常情況下也不會用到該級別。

2.6  JtaTransactionAnnotationParser：策略實現，用於解析parsing JTA（Java Transaction API） 1.2的事務註解。

2.7  Propagation：列舉類中定義了表示傳播行為的列舉值：

       （1）REQUIRED ：如果當前存在事務，則加入該事務；如果當前沒有事務，則建立一個新的事務。

       （2）SUPPORTS ：如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續執行。

       （3）MANDATORY ：如果當前存在事務，則加入該事務；如果當前沒有事務，則丟擲異常。

       （4）REQUIRES_NEW ：建立一個新的事務，如果當前存在事務，則把當前事務掛起。

       （5）NOT_SUPPORTED ：以非事務方式執行，如果當前存在事務，則把當前事務掛起。

       （6）NEVER ：以非事務方式執行，如果當前存在事務，則丟擲異常。

       （7）NESTED ：若當前存在事務，則建立一個事務作為當前事務的巢狀事務來執行；若當前沒有事務，則該取值等價於 REQUIRED 。

2.8  ProxyTransactionManagementConfiguration：配置類，該類註冊Spring基礎架構beans，這些bean是啟用基於代理的註解驅動事務管理所必須的，如AnnotationTransactionAttributeSource、BeanFactoryTransactionAttributeSourceAdvisor、TransactionInterceptor。

2.9  SpringTransactionAnnotationParser ：策略實現，用於解析Spring事務註解。

　　策略（Strategy）模式：該模式定義了一系列演算法，並將每個演算法封裝起來，使它們可以相互替換，且演算法的變化不會影響使用演算法的客戶。策略模式屬於物件行為模式，它通過對演算法進行封裝，把使用演算法的責任和演算法的實現分割開來，並委派給不同的物件對這些演算法進行管理。

2.10  Transactional：該註解類用於在一個方法或者類上描述一個事務屬性。在類級別上應用這個註解（@ Transactional），在預設的在它所有的方法和它所有的子類中應用該註解。

2.11  TransactionAnnotationParser：策略介面，用於解析熟知的事務註解型別。

2.12  TransactionManagementConfigurationSelector：配置啟動事務啟動（EnableTransactionManagement）時，匯入註冊的配置bean。

       它包括AutoProxyRegistrar和ProxyTransactionManagementConfiguration兩大配置塊。

       （1）AutoProxyRegistrar ：負責依賴注入事務的相關屬性配置和注入事務入口類(InfrastructureAdvisorAutoProxyCreator類)；

       （2）ProxyTransactionManagementConfiguration：負責注入事務相關的Bean，包括：

       　　事務切面Bean（BeanFactoryTransactionAttributeSourceAdvisor）；

       　　事務配置屬性bean（TransactionAttributeSource）；

       　　事務攔截器bean（TransactionInterceptor）。

2.13  TransactionManagementConfigurer：被帶有@EnableTransactionManagement註解的配置類實現的介面，這些配置類要指定預設的PlatformTransactionManager bean（或者是ReactiveTransactionManager bean），以用於註解驅動事務管理，而不是通過型別進行查詢。為什麼要這樣，比如在容器中現有兩個PlatformTransactionManager。

 

03 transaction/config

3.1  AnnotationDrivenBeanDefinitionParser ：org.springframework.beans.factory.xml.BeanDefinitionParser介面的實現類，使得使用者可以方便的對所有的基礎架構bean開啟註解驅動的事務界定。

3.2  JtaTransactionManagerBeanDefinitionParser：解析XML配置元素<tx:jta-transaction-manager>，自動檢測WebLogic 和WebSphere伺服器，暴露相應的JtaTransactionManager子類。

3.3  JtaTransactionManagerFactoryBean：一個FactoryBean，等同於XML元素<tx:jta-transaction-manager>，自動檢測WebLogic和WebSphere伺服器，暴露相應的JtaTransactionManager子類。

3.4  TransactionManagementConfigUtils：配置常量，用於子包之間的內部共享。

3.5  TxAdviceBeanDefinitionParser：用於<tx:advice>標籤的BeanDefinitionParser。

3.6  TxNamespaceHandler：名字空間處理器，允許使用XML或註解對宣告式事務進行配置。

 

04 transaction/event

4.1  ApplicationListenerMethodTransactionalAdapter：GenericApplicationListener介面卡，將對事件的處理委託給帶@TransactionalEventListener註解的方法。

4.2  TransactionPhase：列舉類，枚舉了事務事件監聽器應用的時機。有：BEFORE_COMMIT、AFTER_COMMIT、AFTER_ROLLBACK、AFTER_COMPLETION。

4.3  TransactionalEventListener：一個事件監聽器，根據TransactionPhase被呼叫。如果一個事件沒有被活躍的事務所釋出，該事件就被丟棄了除非fallbackExecution標識位設定了。如果事務在執行中，事件會根據其進行的階段被處理。

4.4  TransactionalEventListenerFactory：EventListenerFactory介面實現類，處理帶@ TransactionalEventListener註解的方法。

 

05 transaction/interceptor

5.1  AbstractFallbackTransactionAttributeSource：TransactionAttributeSource介面抽象實現，按如下順序依次嘗試獲取事務註解屬性：

       1）specific target method和method相同簽名的targetClass上的那個方法；

       2）target class – 也就是引數targetClass；

       3）declaring method – 也就是引數method；

       4）declaring class/interface – method的宣告類/所屬類。

       並對所發現的事務註解屬性進行了快取。

5.2  BeanFactoryTransactionAttributeSourceAdvisor：建立BeanFactoryTransactionAttributeSourceAdvisor物件，並新增到Spring容器中，後面的功能就交給Spring AOP去處理。

5.3  CompositeTransactionAttributeSource：這是一個集合代理類，其構造方法要求傳入一些實現，然後在被呼叫的時候迴圈呼叫那些實現直到獲得滿意結果

5.4  DefaultTransactionAttribute：Spring通用的事務屬性實現類。

5.5  DelegatingTransactionAttribute：TransactionAttribute介面的抽象實現類，將所有的呼叫委託給給定的目標TransactionAttribute例項。

5.6  MatchAlwaysTransactionAttributeSource：TransactionAttributeSource最簡單的實現，對於所有的方法都返回同樣的TransactionAttribute。TransactionAttribute可以指定，否則預設為PROPAGATION_REQUIRED（事務傳播屬性：支援當前事務，如果當前沒有事務，就新建一個事務）。

5.7  MethodMapTransactionAttributeSource：在其內部維護了一個Map來根據每個Method來決定TransactionAttribute

5.8  NameMatchTransactionAttributeSource：它是通過方法名的匹配來（可以採用萬用字元）來尋找TransactionAttribute ，當有多個時使用最長的那一個。

5.9  NoRollbackRuleAttribute：繼承自RollbackRuleAttribute，具有和父類RollbackRuleAttribute相反的行為。

5.10  RollbackRuleAttribute：決定一個給定的異常（和其任意的子類）是否應該引發一個回滾。

5.11  RuleBasedTransactionAttribute：TransactionAttribute實現類，通過應用許多回滾規則來計算給定的異常是否要引發事務的回滾，包括正面和負面的。如果沒有和該異常相關的規則，使用DefaultTransactionAttribute（在執行時異常時回滾）。

5.12  TransactionalProxy：標記介面，用於手動建立事務代理。

5.13  TransactionAspectSupport：TransactionAspectSupport 是Spring的事務切面邏輯抽象基類，該類實現了事務切面邏輯，但是自身設計為不能被直接使用，而是作為抽象基類被實現子類使用，應用於宣告式事務使用場景。TransactionInterceptor，或者 AspectJ切面類AnnotationTransactionAspect.aj，JtaAnnotationTransactionAspect.aj都是繼承自該類。

       TransactionAspectSupport為實現子類提供的核心工具方法就是#invokeWithinTransaction，該方法的實現會把一個對目標方法的呼叫包裹(可以理解成AOP中的around模式)在一個事務處理邏輯中。但是該方法何時被呼叫，就交給實現子類了。

       另外TransactionAspectSupport使用了策略設計模式(Strategy)。它會使用一個外部指定的PlatformTransactionManager來執行事務管理邏輯，並且使用一個外部指定的TransactionAttributeSource用來獲取事務定義資訊，也就是@Transactional這種註解上的資訊。

5.14  TransactionAttribute：該介面繼承自TransactionDefinition，在父類TransactionDefinition基礎上增加了boolean rollbackOn(Throwable ex);函式，判斷在給定的異常時是否應該回滾。

5.15  TransactionAttributeEditor：用於事務屬性的屬性編輯器。接受{PROPAGATION_NAME， ISOLATION_NAME， readOnly，timeout_NNNN，+Exception1，-Exception2}型別的字串。

5.16  TransactionAttributeSource：策略介面，被TransactionInterceptor使用，用於取回元資料。

5.17  TransactionAttributeSourceAdvisor：TransactionAttributeSource的增強器，用於包含一個事務攔截器，僅用於事務方法。

5.18  TransactionAttributeSourceEditor：屬性編輯器，用於將一個字串轉換成TransactionAttributeSource。事務屬性字串必須能被該包中的TransactionAttributeEditor解析。

5.19  TransactionAttributeSourcePointcut：切點實現類。Pointcut攔截住了方法，然後使用TransactionAttributeSource去方法和類上獲取事務屬性，如果能獲取到，說明此方法需要參與事務，則進行事務增強，反之則不增強。

5.20  TransactionInterceptor：TransactionInterceptor是Spring框架內建實現的一個MethodInterceptor，用於宣告式事務管理，使用Spring事務基礎設施org.springframework.transaction.PlatformTransactionManager。

       作為一個MethodInterceptor，TransactionInterceptor會被包裹在使用了事務註解的bean元件外面形成該元件的代理物件，當呼叫相應使用事務註解的方法時，TransactionInterceptor的方法攔截器邏輯會被應用，從而完成相應的事務管理。

       TransactionInterceptor繼承自TransactionAspectSupport。主要的事務管理邏輯實現在該基類中。TransactionInterceptor自身主要是實現介面MethodInterceptor定義的方法invoke，觸發被TransactionAspectSupport事務攔截邏輯包圍的目標方法的呼叫。

       關於TransactionInterceptor如何被引入到應用，ProxyTransactionManagementConfiguration是一個很好的例子。在該配置類中，TransactionInterceptor被作為一個bean定義註冊到容器，它會被ProxyTransactionManagementConfiguration註冊到容器的另外一個bean transactionAdvisor使用；應用啟動時Spring的自動代理機制會發現transactionAdvisor以及它所使用的TransactionInterceptor，並將該TransactionInterceptor在建立相應bean的代理物件時包裹到bean外部。

5.21  TransactionProxyFactoryBean：專門為目標Bean生成事務代理的工廠Bean。 每個TransactionProxyFactoryBean為一個目標Bean生成一個事務代理Bean，事務代理的方法改寫了目標Bean的方法，就是在目標Bean的方法執行之前加入開始事務，在目標Bean的方法正常結束之前提交事務，如果遇到特定異常則回滾。

 

06 transaction/jta

6.1  JtaAfterCompletionSynchronization：適配一個JTA Synchronization，在JTA事務完成後呼叫Spring TransactionSynchronization的afterCommit/ afterCompletion回撥函式。

6.2  JtaTransactionManager：PlatformTransactionManager介面關於JTA（Java Transaction API）的實現類。提供對分散式事務管理的支援，並將事務管理委託給Java EE應用伺服器事務管理器。

6.3  JtaTransactionObject：JTA事務物件，表示一個javax.transaction.UserTransaction。作為一個事務物件被Spring的JtaTransactionManager使用。這是一個SPI類，不打算被應用使用。

6.4  ManagedTransactionAdapter：託管JTA事務控制代碼的介面卡，採用一個JTA TransactionManager引用，為其建立一個JTA Transaction控制代碼。

6.5  SimpleTransactionFactory：TransactionFactory策略介面的預設實現類。封裝了一個標準的JTA TransactionManager。

6.6  SpringJtaSynchronizationAdapter：實現JTA  Synchronization介面的介面卡，委託給一個Spring TransactionSynchronization。

6.7  TransactionFactory：策略介面，基於指定的事務特徵建立JTA Transaction物件。其預設的實現類是SimpleTransactionFactory，簡單封裝了一個標準的JTA TransactionManager。

6.8  UserTransactionAdapter：一個JTA UserTransaction控制代碼介面卡，接受一個TransactionManager引用，為其建立一個JTA UserTransaction控制代碼。

6.9  WebLogicJtaTransactionManager：Spring提供的對WebLogic 8.1+應用伺服器事務管理器的介面卡，此介面卡用於對應用伺服器提供的高階事務的支援。

6.10  WebSphereUowTransactionManager：Spring提供的對WebSphere 6.0+應用伺服器事務管理器的介面卡，此介面卡用於對應用伺服器提供的高階事務的支援。

 

07 transaction/reactive

7.1  AbstractReactiveTransactionManager：抽象基類，實現了Spring的標準響應式事務工作流程，作為具體的platform事務管理器的基類。

       該基類提供了以下的工作流處理：

       1） 判斷是否存在一個事務；

       2） 應用相應的事務傳播行為；

       3） 根據需要掛起或重啟事務；

       4） 提交事務時檢查rollback-only標記；

       5） 在回滾中進行相應的更改；

       6） 觸發註冊過的同步回撥。

       子類需要為指定事務的狀態實現指定的模板方法，比如：開始、掛起、重啟、提交、回滾。這些重要的方法現在還是抽象方法，需要在子類中進行實現。其他的一些方法提供了預設實現，也可以實現覆蓋原有的預設實現。

7.2  GenericReactiveTransaction：ReactiveTransaction介面的預設實現，被AbstractReactiveTransactionManager使用。

儲存了所有的狀態資訊，這些資訊會被AbstractReactiveTransactionManager內部使用，包括一個由具體事務管理器實現類決定的通用事務物件。

7.3  ReactiveResourceSynchronization：TransactionSynchronization介面的抽象實現類，通過TransactionSynchronizationManager管理一個資源物件。

7.4  TransactionalOperator：如果是使用的是指令式程式設計，Spring使用TransactionTemplate 來完成程式設計式事務管理，如果是響應式程式設計，那麼使用TransactionalOperator。該類簡化了程式設計式事務管理和事務異常的處理。

7.5  TransactionalOperatorImpl：TransactionalOperator介面的實現類，簡化了程式設計式事務管理和事務異常的處理。

7.6  TransactionCallback：回撥介面，用於響應式事務程式碼。

7.7  TransactionContext ：可變的事務上下文，封裝了事務同步和在單個事務範圍內的資源。

7.8  TransactionContextHolder：響應式事務上下文可變的控制代碼。這個控制代碼儲存了對一個個的TransactionContext的引用。

7.9  TransactionContextManager：註冊和獲取事務上下文。

7.10  TransactionSynchronization：用於響應式事務同步回撥的介面，被AbstractReactiveTransactionManager所支援。

7.11  TransactionSynchronizationManager：為每個訂閱的上下文管理資源和事務同步。被資源管理程式碼使用，但不是用於典型的應用程式碼。

7.12  TransactionSynchronizationUtils：功能方法，用於在所有現有註冊的synchronizations中，觸發指定的TransactionSynchronization回撥方法。

 

08 transaction/support

8.1  AbstractPlatformTransactionManager：AbstractPlatformTransactionManager抽象類，實現了PlatformTransactionManager介面。負責實現整個事務管理和執行過程中的公共行為和通用實現邏輯，提供了一些預設的方法實現，比如提交和回滾的邏輯實現。

       一般自定義事務管理類的時候，不是直接去實現PlatformTransactionManager介面，而是通過繼承AbstractPlatformTransactionManager來完成，AbstractPlatformTransactionManager的作用就相當於一個模板，提供固有的方法實現。通用的事務處理流程框架是由AbstractPlatformTransactionManager來提供的，具體的底層事務處理實現，由Platf