Spring框架之事務源碼完全解析
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。
參考：//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源碼完全解析
博眾家之所長，集群英之薈萃。遴選各IT領域精品雄文！
歡迎關注「IT架構精選」
