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來提供的，具體的底層事務處理實現，由PlatformTransactionManager的具體實現類來實現，如 DataSourceTransactionManager 、JtaTransactionManager和 HibernateTransactionManager等。
AbstractPlatformTransactionManager抽象類提供了以下工作流程處理：
1）確定如果有現有的事務；
2）應用適當的傳播行為；
3）如果有必要暫停和恢復事務；
4）提交時檢查rollback-only標記；
5）應用適當的修改當回滾（實際回滾或設置rollback-only）
6）觸發同步回調注冊（如果事務同步是激活的）。
子類必須實現為特定的事務狀態實現模板方法。例如：開始、掛起、重啟、提交、回滾。這些重要的方法是抽象方法，需要在子類中進行實現，其余的提供了默認實現，子類也可覆蓋實現。
8.2 AbstractTransactionStatus：對於PlatformTransactionManager有默認的抽象類方法實現模板，那TransactionStatus也有，其對應的模板實現類就是AbstractTransactionStatus。
8.3 CallbackPreferringPlatformTransactionManager：PlatformTransactionManager接口的拓展，暴露了一個方法，用於使用事務執行一個給定的回調。
8.4 DefaultTransactionDefinition：TransactionDefinition接口的默認實現類，體用了bean類型的配置和合理的默認值（PROPAGATION_REQUIRED， ISOLATION_DEFAULT，TIMEOUT_DEFAULT，readOnly=false）。作為TransactionTemplate和DefaultTransactionAttribute的父類。
8.5 DefaultTransactionStatus：TransactionDefinition沒有提供對應的抽象類，而是直接提供了一個默認的實現類DefaultTransactionDefinition。我感覺是因為TransactionDefinition的主要的內容是屬性，方法比較簡單，就沒有必要提供一個抽象模板實現了。
8.6 DelegatingTransactionDefinition：實現TransactionDefinition接口的抽象類，將所有的調用委托給給定的目標TransactionDefinition實例。
8.7 ResourceHolder：被資源持有者實現的通用接口。允許需要的時候Spring事務架構內省和重置這些資源持有者。
8.8 ResourceHolderSupport：資源句柄支持類，作用在於方便ResourceHolder接口的實現。
8.9 ResourceHolderSynchronization：實現了TransactionSynchronization接口，通過TransactionSynchronizationManager來管理資源句柄。用來同步資源狀態的，這里的資源就是Spring 事務框架中的資源的概念，就是JDBC里的Connection，Hibernate里的Session，JPA里的EntityManager，Kafka里的Producer。
8.10 ResourceTransactionDefinition：TransactionDefinition接口的拓展，表示一個資源事務，特別是事務資源是否准備好局部優化。
8.11 ResourceTransactionManager：PlatformTransactionManager接口的拓展接口，表示一個本地的資源事務管理器，操作單個的目標資源。這些事務管理器和JTA事務管理器不同，它們不為一個公開數字的資源使用XA事務等級，而是專注利用本機功能，簡化單個目標資源。
8.12 SimpleTransactionScope：基於事務的Scope接口的實現類。
8.13 SimpleTransactionStatus：TransactionStatus接口的簡單實現類。繼承自AbstractTransactionStatus，增加了一個"newTransaction"標識。
8.14 SmartTransactionObject：用於被事務對象實現的接口，這些事務對象能夠返回一個內部的rollback-only標識，通常從另一個參與和標記為rollback-only的事務獲取。
8.15 TransactionCallback：回調接口，用於事務代碼，和TransactionTemplate的execute方法一起使用，常作為一個方法實現中的匿名類。執行事務處理后有返回值，如find要返回結果集(List)。
8.16 TransactionCallbackWithoutResult：方便對TransactionCallback接口的實現，允許實現一個不帶返回值的doInTransaction版本，比如不需要返回statement，如save、update、delete等等。
8.17 TransactionOperations：指定了基本的事務執行操作的接口。被TransactionTemplate所實現。一般不直接使用，但是可以方便測試，因為其可容易的mocked或stubbed。
8.18 TransactionSynchronization：用於事務同步的接口。被AbstractPlatformTransactionManager支持。
8.19 TransactionSynchronizationAdapter：TransactionSynchronization簡單適配器，包含了方法的空實現。
8.20 TransactionSynchronizationManager：對每個線程的資源和事務同步進行管理。被資源管理代碼使用，一般不被應用代碼使用。
8.21 TransactionSynchronizationUtils：功能函數，用於在所有當前注冊過的synchronizations觸發指定的TransactionSynchronization回調方法。
8.22 TransactionTemplate：TransactionTemplate的編程式事務管理是使用模板方法設計模式對原始事務管理方式的封裝。TransactionTemplate主要依賴於execute(TransactionCallback<T> action)方法執行事務管理。
Spring可以支持編程式事務和聲明式事務。
（1）Spring提供的最原始的事務管理方式是基於TransactionDefinition、PlatformTransactionManager、TransactionStatus 編程式事務。
（2）而TransactionTemplate的編程式事務管理是使用模板方法設計模式對原始事務管理方式的封裝。需要自己手動在每個業務方法中實現事務。
（3）基於 @Transactional 的方式將聲明式事務管理簡化到了極致。
8.23 WithoutTransactionOperations：TransactionOperations接口的實現類，在沒有實際事務情況下執行一個給定的TransactionCallback。
參考：https://www.cnblogs.com/davidwang456/p/4309038.html
拓展閱讀：
Spring框架之beans源碼完全解析
Spring框架之AOP源碼完全解析
Spring框架之jdbc源碼完全解析
Spring源碼深度解析之數據庫連接JDBC
Spring框架之jms源碼完全解析
Spring框架之事務源碼完全解析
Spring源碼深度解析之事務
Spring源碼深度解析之Spring MVC
Spring框架之websocket源碼完全解析
WebSocket協議中文版
Spring框架之spring-web web源碼完全解析
Spring框架之spring-web http源碼完全解析
Spring框架之spring-webmvc源碼完全解析