本文將按照宣告式事務的五個特性進行介紹：

1. 事務傳播機制
2. 事務隔離機制
3. 只讀
4. 事務超時
5. 回滾規則

Spring事務傳播機制

事務的特性

• 原子性（Atomicity）：事務是一個原子操作，由一系列動作組成。事務的原子性確保動作要麼全部完成，要麼完全不起作用。
• 一致性（Consistency）：一旦事務完成（不管成功還是失敗），系統必須確保它所建模的業務處於一致的狀態，而不會是部分完成部分失敗。在現實中的資料不應該被破壞。
• 隔離性（Isolation）：可能有許多事務會同時處理相同的資料，因此每個事務都應該與其他事務隔離開來，防止資料損壞。
• 永續性（Durability）：一旦事務完成，無論發生什麼系統錯誤，它的結果都不應該受到影響，這樣就能從任何系統崩潰中恢復過來。通常情況下，事務的結果被寫到持久化儲存器中。

Spring事務的配置方式

Spring支援程式設計式事務管理以及宣告式事務管理兩種方式。

1. 程式設計式事務管理

程式設計式事務管理是侵入性事務管理，使用TransactionTemplate或者直接使用PlatformTransactionManager，對於程式設計式事務管理，Spring推薦使用TransactionTemplate。

2. 宣告式事務管理

宣告式事務管理建立在AOP之上，其本質是對方法前後進行攔截，然後在目標方法開始之前建立或者加入一個事務，執行完目標方法之後根據執行的情況提交或者回滾。
程式設計式事務每次實現都要單獨實現，但業務量大功能複雜時，使用程式設計式事務無疑是痛苦的，而宣告式事務不同，宣告式事務屬於無侵入式，不會影響業務邏輯的實現，只需要在配置檔案中做相關的事務規則宣告或者通過註解的方式，便可以將事務規則應用到業務邏輯中。
顯然宣告式事務管理要優於程式設計式事務管理，這正是Spring倡導的非侵入式的程式設計方式。唯一不足的地方就是宣告式事務管理的粒度是方法級別，而程式設計式事務管理是可以到程式碼塊的，但是可以通過提取方法的方式完成宣告式事務管理的配置。

事務的傳播機制

事務的傳播性一般用在事務巢狀的場景，比如一個事務方法裡面呼叫了另外一個事務方法，那麼兩個方法是各自作為獨立的方法提交還是內層的事務合併到外層的事務一起提交，這就是需要事務傳播機制的配置來確定怎麼樣執行。
常用的事務傳播機制如下：

• PROPAGATION_REQUIRED
  Spring預設的傳播機制，能滿足絕大部分業務需求，如果外層有事務，則當前事務加入到外層事務，一塊提交，一塊回滾。如果外層沒有事務，新建一個事務執行
• PROPAGATION_REQUES_NEW
  該事務傳播機制是每次都會新開啟一個事務，同時把外層事務掛起，噹噹前事務執行完畢，恢復上層事務的執行。如果外層沒有事務，執行當前新開啟的事務即可
• PROPAGATION_SUPPORT
  如果外層有事務，則加入外層事務，如果外層沒有事務，則直接使用非事務方式執行。完全依賴外層的事務
• PROPAGATION_NOT_SUPPORT
  該傳播機制不支援事務，如果外層存在事務則掛起，執行完當前程式碼，則恢復外層事務，無論是否異常都不會回滾當前的程式碼
• PROPAGATION_NEVER
  該傳播機制不支援外層事務，即如果外層有事務就丟擲異常
• PROPAGATION_MANDATORY
  與NEVER相反，如果外層沒有事務，則丟擲異常
• PROPAGATION_NESTED
  該傳播機制的特點是可以儲存狀態儲存點，當前事務回滾到某一個點，從而避免所有的巢狀事務都回滾，即各自回滾各自的，如果子事務沒有把異常吃掉，基本還是會引起全部回滾的。

傳播規則回答了這樣一個問題：一個新的事務應該被啟動還是被掛起，或者是一個方法是否應該在事務性上下文中執行。

事務的隔離級別

事務的隔離級別定義一個事務可能受其他併發務活動活動影響的程度，可以把事務的隔離級別想象為這個事務對於事物處理資料的自私程度。

在一個典型的應用程式中，多個事務同時執行，經常會為了完成他們的工作而操作同一個資料。併發雖然是必需的，但是會導致以下問題：

1. 髒讀（Dirty read）
   髒讀發生在一個事務讀取了被另一個事務改寫但尚未提交的資料時。如果這些改變在稍後被回滾了，那麼第一個事務讀取的資料就會是無效的。

2. 不可重複讀（Nonrepeatable read）
   不可重複讀發生在一個事務執行相同的查詢兩次或兩次以上，但每次查詢結果都不相同時。這通常是由於另一個併發事務在兩次查詢之間更新了資料。

   不可重複讀重點在修改。

3. 幻讀（Phantom reads）
   幻讀和不可重複讀相似。當一個事務（T1）讀取幾行記錄後，另一個併發事務（T2）插入了一些記錄時，幻讀就發生了。在後來的查詢中，第一個事務（T1）就會發現一些原來沒有的額外記錄。

   幻讀重點在新增或刪除。

在理想狀態下，事務之間將完全隔離，從而可以防止這些問題發生。然而，完全隔離會影響效能，因為隔離經常涉及到鎖定在資料庫中的記錄（甚至有時是鎖表）。完全隔離要求事務相互等待來完成工作，會阻礙併發。因此，可以根據業務場景選擇不同的隔離級別。

隔離級別	含義
ISOLATION_DEFAULT	使用後端資料庫預設的隔離級別
ISOLATION_READ_UNCOMMITTED	允許讀取尚未提交的更改。可能導致髒讀、幻讀或不可重複讀。
ISOLATION_READ_COMMITTED	（Oracle 預設級別）允許從已經提交的併發事務讀取。可防止髒讀，但幻讀和不可重複讀仍可能會發生。
ISOLATION_REPEATABLE_READ	（MYSQL預設級別）對相同欄位的多次讀取的結果是一致的，除非資料被當前事務本身改變。可防止髒讀和不可重複讀，但幻讀仍可能發生。
ISOLATION_SERIALIZABLE	完全服從ACID的隔離級別，確保不發生髒讀、不可重複讀和幻影讀。這在所有隔離級別中也是最慢的，因為它通常是通過完全鎖定當前事務所涉及的資料表來完成的。

只讀

如果一個事務只對資料庫執行讀操作，那麼該資料庫就可能利用那個事務的只讀特性，採取某些優化措施。通過把一個事務宣告為只讀，可以給後端資料庫一個機會來應用那些它認為合適的優化措施。由於只讀的優化措施是在一個事務啟動時由後端資料庫實施的， 因此，只有對於那些具有可能啟動一個新事務的傳播行為（PROPAGATION_REQUIRES_NEW、PROPAGATION_REQUIRED、 ROPAGATION_NESTED）的方法來說，將事務宣告為只讀才有意義。

事務超時

為了使一個應用程式很好地執行，它的事務不能執行太長時間。因此，宣告式事務的下一個特性就是它的超時。

假設事務的執行時間變得格外的長，由於事務可能涉及對資料庫的鎖定，所以長時間執行的事務會不必要地佔用資料庫資源。這時就可以宣告一個事務在特定秒數後自動回滾，不必等它自己結束。

由於超時時鐘在一個事務啟動的時候開始的，因此，只有對於那些具有可能啟動一個新事務的傳播行為（PROPAGATION_REQUIRES_NEW、PROPAGATION_REQUIRED、ROPAGATION_NESTED）的方法來說，宣告事務超時才有意義。

回滾規則

在預設設定下，事務只在出現執行時異常（runtime exception）時回滾，而在出現受檢查異常（checked exception）時不回滾（這一行為和EJB中的回滾行為是一致的）。
不過，可以宣告在出現特定受檢查異常時像執行時異常一樣回滾。同樣，也可以宣告一個事務在出現特定的異常時不回滾，即使特定的異常是執行時異常。

Spring宣告式事務配置參考

事物配置中有哪些屬性可以配置?以下只是簡單的使用參考

1. 事務的傳播性：
   @Transactional(propagation=Propagation.REQUIRED)
2. 事務的隔離級別：
   @Transactional(isolation = Isolation.READ_UNCOMMITTED)

讀取未提交資料(會出現髒讀, 不可重複讀) 基本不使用

1. 只讀：
   @Transactional(readOnly=true)
   該屬性用於設定當前事務是否為只讀事務，設定為true表示只讀，false則表示可讀寫，預設值為false。
2. 事務的超時性：
   @Transactional(timeout=30)
3. 回滾：
   指定單一異常類：@Transactional(rollbackFor=RuntimeException.class)
   指定多個異常類：@Transactional(rollbackFor={RuntimeException.class, Exception.class})

該屬性用於設定需要進行回滾的異常類陣列，當方法中丟擲指定異常陣列中的異常時，則進行事務回滾。

最後，限於筆者經驗水平有限，歡迎讀者就文中的觀點提出寶貴的建議和意見。如果想獲得更多的學習資源或者想和更多的技術愛好者一起交流，可以關注我的公眾號『全菜工程師小輝』後臺回覆關鍵詞領取學習資料、進入前後端技術交流群和程式設計師副業群。同時也可以加入程式設計師副業群Q群：735764906 一起交流。

相關推薦