18.7.2

概述

Spring Framework對事務管理提供了一致的抽象，其特點如下：
為不同的事務API提供一致的編程模型，比如JTA(Java Transaction API), JDBC, Hibernate, JPA(Java Persistence API和JDO(Java Data Objects)
支持聲明式事務管理，特別是基于注解的聲明式事務管理，簡單易用
提供比其他事務API如JTA更簡單的編程式事務管理API
與spring數據訪問抽象的完美集成

事務管理方式

spring支持編程式事務管理和聲明式事務管理兩種方式。
編程式事務管理使用TransactionTemplate或者直接使用底層的PlatformTransactionManager。對于編程式事務管理，spring推薦使用TransactionTemplate。
聲明式事務管理建立在AOP之上的。其本質是對方法前后進行攔截，然后在目標方法開始之前創建或者加入一個事務，在執行完目標方法之后根據執行情況提交或者回滾事務。
聲明式事務最大的優點就是不需要通過編程的方式管理事務，這樣就不需要在業務邏輯代碼中摻雜事務管理的代碼，只需在配置文件中做相關的事務規則聲明(或通過基于@Transactional注解的方式)，便可以將事務規則應用到業務邏輯中。
顯然聲明式事務管理要優于編程式事務管理，這正是spring倡導的非侵入式的開發方式。
和編程式事務相比，聲明式事務唯一不足地方是，后者的最細粒度只能作用到方法級別，無法做到像編程式事務那樣可以作用到代碼塊級別。但是即便有這樣的需求，也存在很多變通的方法，比如，可以將需要進行事務管理的代碼塊獨立為方法等等。
聲明式事務管理也有兩種常用的方式，一種是基于tx和aop名字空間的xml配置文件，另一種就是基于@Transactional注解。顯然基于注解的方式更簡單易用，更清爽。

自動提交(AutoCommit)與連接關閉時的是否自動提交

自動提交

默認情況下，數據庫處于自動提交模式。每一條語句處于一個單獨的事務中，在這條語句執行完畢時，如果執行成功則隱式的提交事務，如果執行失敗則隱式的回滾事務。
spring將底層連接的自動提交特性設置為false，因為對于正常的事務管理，是一組相關的操作處于一個事務之中，因此必須關閉數據庫的自動提交模式。（一個事務里面有多個數據庫操作，比如多個save和update，save執行完了，并沒有提交給數據庫，等全部執行完一同提交數據庫）

快速入門

在Spring Boot中，當我們使用了spring-boot-starter-jdbc或spring-boot-starter-data-jpa依賴的時候，框 架會自動默認分別注入DataSourceTransactionManager或JpaTransactionManager。所以我們不需要任何額外 配置就可以用@Transactional注解進行事務的使用。
如果Spring容器中存在多個 PlatformTransactionManager 實例，并且沒有實現接口 TransactionManagementConfigurer 指定默認值，在我們在方法上使用注解 @Transactional 的時候，就必須要用value指定，如果不指定，則會拋出異常。
對于系統需要提供默認事務管理的情況下，實現接口 TransactionManagementConfigurer 指定。
對有的系統，為了避免不必要的問題，在業務中必須要明確指定 @Transactional 的 value 值的情況下。不建議實現接口 TransactionManagementConfigurer，這樣控制臺會明確拋出異常，開發人員就不會忘記主動指定。
當我們項目較大較復雜時（比如，有多個數據源等），這時候需要在聲明事務時，指定不同的事務管理器。
在聲明事務時，只需要通過value屬性指定配置的事務管理器名即可，例如：@Transactional(value="transactionManagerPrimary") 。

spring事務特性

spring所有的事務管理策略類都繼承自org.springframework.transaction.PlatformTransactionManager接口

事務隔離級別

隔離級別是指若干個并發的事務之間的隔離程度。TransactionDefinition 接口中定義了五個表示隔離級別的常量：

TransactionDefinition.ISOLATION_DEFAULT：這是默認值，表示使用底層數據庫的默認隔離級別。對大部分數據庫而言，通常這值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
TransactionDefinition.ISOLATION_READ_UNCOMMITTED：該隔離級別表示一個事務可以讀取另一個事務修改但還沒有提交的數據。該級別不能防止臟讀，不可重復讀和幻讀，因此很少使用該隔離級別。比如PostgreSQL實際上并沒有此級別。
TransactionDefinition.ISOLATION_READ_COMMITTED：該隔離級別表示一個事務只能讀取另一個事務已經提交的數據。該級別可以防止臟讀，這也是大多數情況下的推薦值。
TransactionDefinition.ISOLATION_REPEATABLE_READ：該隔離級別表示一個事務在整個過程中可以多次重復執行某個查詢，并且每次返回的記錄都相同。該級別可以防止臟讀和不可重復讀。
TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說，該級別可以防止臟讀、不可重復讀以及幻讀。但是這將嚴重影響程序的性能。通常情況下也不會用到該級別。

事務傳播行為

所謂事務的傳播行為是指，如果在開始當前事務之前，一個事務上下文已經存在，此時有若干選項可以指定一個事務性方法的執行行為。在TransactionDefinition定義中包括了如下幾個表示傳播行為的常量：

TransactionDefinition.PROPAGATION_REQUIRED：如果當前存在事務，則加入該事務；如果當前沒有事務，則創建一個新的事務。這是默認值。
TransactionDefinition.PROPAGATION_REQUIRES_NEW：創建一個新的事務，如果當前存在事務，則把當前事務掛起。
TransactionDefinition.PROPAGATION_SUPPORTS：如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續運行。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事務方式運行，如果當前存在事務，則把當前事務掛起。
TransactionDefinition.PROPAGATION_NEVER：以非事務方式運行，如果當前存在事務，則拋出異常。
TransactionDefinition.PROPAGATION_MANDATORY：如果當前存在事務，則加入該事務；如果當前沒有事務，則拋出異常。
TransactionDefinition.PROPAGATION_NESTED：如果當前存在事務，則創建一個事務作為當前事務的嵌套事務來運行；如果當前沒有事務，則該取值等價于TransactionDefinition.PROPAGATION_REQUIRED。

（事務傳播性理解：在我們用SSH開發項目的時候，我們一般都是將事務設置在Service層 那么當我們調用Service層的一個方法的時候它能夠保證我們的這個方法中執行的所有的對數據庫的更新操作保持在一個事務中，在事務層里面調用的這些方法要么全部成功，要么全部失敗。如果你在你的Service層的這個方法中，除了調用了Dao層的方法之外，還調用了本類的其他的Service方法，那么在調用其他的Service方法的時候，這個事務是怎么規定的呢，我必須保證我在我方法里掉用的這個方法與我本身的方法處在同一個事務中，否則如果保證事物的一致性。
參考：https://blog.csdn.net/wwh578867817/article/details/51736723）

事務超時

所謂事務超時，就是指一個事務所允許執行的最長時間，如果超過該時間限制但事務還沒有完成，則自動回滾事務。在 TransactionDefinition 中以 int 的值來表示超時時間，其單位是秒。
默認設置為底層事務系統的超時值，如果底層數據庫事務系統沒有設置超時值，那么就是none，沒有超時限制。

事務只讀屬性

只讀事務用于客戶代碼只讀但不修改數據的情形，只讀事務用于特定情景下的優化，比如使用Hibernate的時候。默認為讀寫事務。

spring事務回滾規則

指示spring事務管理器回滾一個事務的推薦方法是在當前事務的上下文內拋出異常。spring事務管理器會捕捉任何未處理的異常，然后依據規則決定是否回滾拋出異常的事務。
默認配置下，spring只有在拋出的異常為運行時和unchecked異常時才回滾該事務，也就是拋出的異常為RuntimeException的子類(Errors也會導致事務回滾)，而拋出checked異常則不會導致事務回滾。
可以明確的配置在拋出那些異常時回滾事務，包括checked異常。也可以明確定義那些異常拋出時不回滾事務。
還可以編程性的通過setRollbackOnly()方法來指示一個事務必須回滾，在調用完setRollbackOnly()后你所能執行的唯一操作就是回滾。

@Transactional注解

屬性 類型 描述
value String 可選的限定描述符，指定使用的事務管理器
propagation enum: Propagation 可選的事務傳播行為設置
isolation enum: Isolation 可選的事務隔離級別設置
readOnly boolean 讀寫或只讀事務，默認讀寫
timeout int (in seconds granularity) 事務超時時間設置
rollbackFor Class對象數組，必須繼承自Throwable 導致事務回滾的異常類數組
rollbackForClassName 類名數組，必須繼承自Throwable 導致事務回滾的異常類名字數組
noRollbackFor Class對象數組，必須繼承自Throwable 不會導致事務回滾的異常類數組
noRollbackForClassName 類名數組，必須繼承自Throwable 不會導致事務回滾的異常類名字數組

用法

@Transactional 可以作用于接口、接口方法、類以及類方法上。當作用于類上時，該類的所有 public 方法將都具有該類型的事務屬性，同時，我們也可以在方法級別使用該標注來覆蓋類級別的定義。
雖然 @Transactional 注解可以作用于接口、接口方法、類以及類方法上，但是 Spring 建議不要在接口或者接口方法上使用該注解，因為這只有在使用基于接口的代理時它才會生效。另外， @Transactional 注解應該只被應用到 public 方法上，這是由 Spring AOP 的本質決定的。如果你在 protected、private 或者默認可見性的方法上使用 @Transactional 注解，這將被忽略，也不會拋出任何異常。
默認情況下，只有來自外部的方法調用才會被AOP代理捕獲，也就是，類內部方法調用本類內部的其他方法并不會引起事務行為，即使被調用方法使用@Transactional注解進行修飾。

注意事項：

1、使用了@Transactional的方法，對同一個類里面的方法調用， @Transactional無效。比如有一個類Test，它的一個方法A，A再調用Test本類的方法B（不管B是否public還是private），但A沒有聲明注解事務，而B有。則外部調用A之后，B的事務是不會起作用的。（經常在這里出錯）
2、使用了@Transactional的方法，只能是public，@Transactional注解的方法都是被外部其他類調用才有效，故只能是public。道理和上面的有關聯。故在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不會報錯，但事務無效。
（理解是必須外部調用的public的事務才會起作用）
3、經過測試，效果如下：
A.拋出受查異常XXXException，事務會回滾。
B.拋出運行時異常NullPointerException，事務會回滾。
C.Quartz中，execute直接調用加了@Transactional方法，可以回滾；間接調用，不會回滾。（即上文3點提到的）
D.異步任務中，execute直接調用加了@Transactional方法，可以回滾；間接調用，不會回滾。（即上文3點提到的）
E.在action中加上@Transactional，不會回滾。切記不要在action中加上事務。
F.在service中加上@Transactional，如果是action直接調該方法，會回滾，如果是間接調，不會回滾。（即上文3提到的）
G.在service中的private加上@Transactional，事務不會回滾。
參考：https://www.cnblogs.com/yepei/p/4716112.html
https://www.cnblogs.com/sllina/p/5694805.html
https://blog.csdn.net/kinseygeek/article/details/54931710

源碼分析：https://blog.csdn.net/qq_38182963/article/details/78891044