探索 Spring 事務的奧秘
在當今的軟件開發領域,事務管理是確保數據完整性和一致性的關鍵環節。而 Spring 事務,作為一個強大且廣泛應用的事務管理機制,在構建可靠、高效的應用程序中發揮著至關重要的作用。
當我們踏上對 Spring 事務的探索之旅,就仿佛打開了一扇通往復雜而又精妙世界的大門。在這里,我們將見證事務如何在幕后默默工作,協調各種操作,保障數據的準確性和穩定性。它如同一位無聲的守護者,精心呵護著系統的運行。
無論是應對復雜的業務邏輯還是處理大規模的數據交互,Spring 事務都展現出了其非凡的能力和靈活性。通過深入剖析它的原理、特性和應用場景,我們能夠更好地理解如何充分發揮其優勢,解決實際開發中面臨的諸多挑戰。讓我們一同開啟這場精彩的旅程,去揭開 Spring 事務那神秘的面紗,探尋其中蘊含的無盡智慧與可能。
一、詳解Spring中的事務
1.什么是事務
事務在邏輯上可以認為就是把一組操作看作一個動作。這個動作的內容要么都成功,要么都失敗,這樣才能保證結果的準確性、一致性。
如下代碼所示,如果下面這段代碼兩個插入操作不屬于同一個事務的話,結束時只有張三被插入和李四沒有插入,不符合業務上的準確性。
使用事務進行數據庫增刪改查操作時,必須保證當前使用的數據庫引擎支持事務,以MySQL為例,MySQL默認引擎為innodb,他就是支持事務的。若時myisam則不支持事務,無法實現數據回滾。
public void transaction_exception_nested_nested(){
User1 user1=new User1();
user1.setName("張三");
user1Service.addNested(user1);
//報錯
throw new RuntimeException();
User2 user2=new User2();
user2.setName("李四");
user2Service.addNested(user2);
}
2.事務的特性ACID簡介
英文翻譯成中文大致是:原子性、隔離性、一致性、持久性。分別代表的含義是:
- 原子性(Atomicity): 屬于同一個事務的操作要么都成功,要么都失敗,直接回滾,數據庫的數據像是沒有被動過一樣。
- 一致性(Consistency):在事務開始前和事務結束后,數據庫的完整性沒有被破壞,即操作符合數據庫級聯回滾、預設約束、觸發器要求。
- 隔離性(Isolation)數據庫允許并發操作,使用準確的隔離性原則才能保證數據一致性,而隔離級別有:讀未提交(Read uncommitted)、讀已提交(read committed)、可重復讀(repeatable read)、串行化(Serializable)。
- 持久性(Durability):持久化的數據不會丟失,即使系統發生故障。
3.Spring支持的兩種事務管理
有兩種姿勢,分別是手動式事務和注解式事務,前者是手動的,比較少使用,對應的類是TransactionTemplate或者TransactionManager,使用示例如下所示:
@Autowired
private TransactionTemplate transactionTemplate;
public void testTransaction() {
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
@Override
protected void doInTransactionWithoutResult(TransactionStatus transactionStatus) {
try {
// .... 業務代碼
} catch (Exception e){
//回滾
transactionStatus.setRollbackOnly();
}
}
});
}
或者下面這樣一段代碼,都是通過都是傳入需要進行事務管理的bean定義,進行手動操作管理:
@Autowired
private PlatformTransactionManager transactionManager;
public void testTransaction() {
TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
// .... 業務代碼
transactionManager.commit(status);
} catch (Exception e) {
transactionManager.rollback(status);
}
}
而后者就比較常用了,基于注解(底層是通過AOP實現的),使用的示例代碼如下所示:
@Transactional
public void transaction_exception_nested_nested(){
User1 user1=new User1();
user1.setName("張三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addNested(user2);
throw new RuntimeException();
}
4.Spring事務隔離級別和傳播行為有哪些(筆試常問)
先來說說事務隔離級別:
- default(默認):PlatfromTransactionManager默認的隔離級別,使用數據庫默認的事務隔離級別,除了default 其它幾個Spring事務隔離級別與JDBC事務隔離級別相對應。
- read_uncommited(讀未提交):一個事務可以讀取另外一個事務未提交的數據,這可能出現臟讀 而且不可重復度,出現幻像讀等。
- read_commited(讀已提交):一個事務可以讀取另一個事務已經提交的數據,不可以讀取未提交的數據 可以避免臟讀 但是無法避免不可重復讀和幻像讀。
- repeatTable_read(可重復讀):一個事務可以讀取另外一個事務已經提交的數據,可以避免臟讀的前提下 ,也可以避免不可重復讀,但是還是無法避免幻像讀。
- serializable(串行化):這是一個花費較高但是比較可靠的事務隔離級別,可以避免臟讀 幻像讀和不可重復讀(事務被處理為順序執行)
Spring事務傳播屬性:
- required(默認屬性):Propagation.REQUIRED內外部屬于統一事務,一個回滾全部回滾。(后文會有代碼演示)
- Mandatory:如果當前存在事務,則支持當前事務,如果不存在事務,則拋出異常
- Never:以非事務方式執行,如果當前存在事務,則拋出異常
- Supports:如果當前存在事務,則支持當前事務,.如果不存在事務,以非事務方式執行
- Not_Supports:以非事務方式執行操作,如果存在事務,則掛起當前事務
- required_new:在外圍方法開啟事務的情況下Propagation.REQUIRES_NEW修飾的內部方法依然會單獨開啟獨立事務,且與外部方法事務也獨立,內部方法之間、內部方法和外部方法事務均相互獨立,互不干擾。
- Nested:嵌套,支持當前事務,內層事務的執行失敗不會導致外層事務的回滾,但是外層事務的回滾會影響內層事務導致內層事務隨外層事務一同回滾.
二、事務傳播行為進階知識
1.前置鋪墊,代碼示例編寫
為了更好的解答后續的問題,這里我們給出了一個示例,user1表的service:
@Service
public class User1Service {
@Resource
private User1Mapper user1Mapper;
@Transactional(propagation = Propagation.REQUIRED)
public void addRequired(User1 user){
user1Mapper.insert(user);
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void addRequiresNew(User1 user){
user1Mapper.insert(user);
}
@Transactional(propagation = Propagation.NESTED)
public void addNested(User1 user){
user1Mapper.insert(user);
}
}
user2表的service,可以看到對于數據庫的操作都在注解上標出不同的傳播行為:
@Service
public class User2Service {
@Resource
private User2Mapper user2Mapper;
@Transactional(propagation = Propagation.REQUIRED)
public void addRequired(User2 user){
user2Mapper.insert(user);
}
@Transactional(propagation = Propagation.REQUIRED)
public void addRequiredException(User2 user){
user2Mapper.insert(user);
throw new RuntimeException();
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void addRequiresNew(User2 user){
user2Mapper.insert(user);
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void addRequiresNewException(User2 user){
user2Mapper.insert(user);
throw new RuntimeException();
}
@Transactional(propagation = Propagation.NESTED)
public void addNested(User2 user){
user2Mapper.insert(user);
}
@Transactional(propagation = Propagation.NESTED)
public void addNestedException(User2 user){
user2Mapper.insert(user);
throw new RuntimeException();
}
}
2. TransactionDefinition.PROPAGATION_REQUIRED
它是Spring的默認傳播行為,說白了發生嵌套在內部的事務會和外部的事務融合,所以外部事務報錯了內部事務也會回滾。
如下面這段代碼,外部的方法沒有加事務,且user1Service、user2Service的方法都是PROPAGATION_REQUIRED這個傳播級別,所以外部報錯不影響兩者的內部提交
/**
* 彼此都有獨立的事務,外部沒有開事務,所以兩者數據都會入庫
*/
@GetMapping("/test/add1")
public void notransaction_exception_required_required() {
User1 user1 = new User1();
user1.setName("張三");
user1Service.addRequired(user1);
User2 user2 = new User2();
user2.setName("李四");
user2Service.addRequired(user2);
throw new RuntimeException();
}
然后我們再來看看這樣一段代碼,外部沒有加事務,所以內部兩個事務彼此獨立。可以看到user2Service報錯,所以只有user1Service插入成功:
@GetMapping("/test/add2")
public void notransaction_required_required_exception() {
//插入成功
User1 user1 = new User1();
user1.setName("張三");
user1Service.addRequired(user1);
//事務是獨立的插入失敗
User2 user2 = new User2();
user2.setName("李四");
user2Service.addRequiredException(user2);
throw new RuntimeException();
}
最后在看看這個,外部加了事務,也是REQUIRED,所以內部兩個事務與其融合成為一個事務,當外部方法報錯,兩者插入操作都失敗,數據直接回滾:
/**
* 外部開啟事務,報錯均回滾
*/
@GetMapping("/test/add3")
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_exception_required_required() {
User1 user1 = new User1();
user1.setName("張三");
user1Service.addRequired(user1);
User2 user2 = new User2();
user2.setName("李四");
user2Service.addRequired(user2);
throw new RuntimeException();
}
再來看看一個比較好玩的,內外部都有事務,第2個內部事務報錯,由于三者事務融為一體,所以user2Service的錯誤被外部transaction_required_required_exception方法感知,user1Service插入也是失敗的,所以這個方法兩張表都沒有插入數據
@GetMapping("/test/add4")
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_required_required_exception() {
User1 user1 = new User1();
user1.setName("張三");
user1Service.addRequired(user1);
User2 user2 = new User2();
user2.setName("李四");
//錯誤被外部感知,所以所有user1的插入也被回滾了
user2Service.addRequiredException(user2);
}
這個也比較特殊,由于三個事務合為一體,所以即使user2Service報錯不被感知,兩張表的數據也還是沒有插入:
@GetMapping("/test/add5")
@Transactional
public void transaction_required_required_exception_try() {
User1 user1 = new User1();
user1.setName("張三");
user1Service.addRequired(user1);
User2 user2 = new User2();
user2.setName("李四");
try {
//雖然異常被捕獲,但是三個內外部事務融合了,一個報錯就全部插入回滾
user2Service.addRequiredException(user2);
} catch (Exception e) {
System.out.println("方法回滾");
}
}
總結:Propagation.REQUIRED內外部屬于統一事務,一個回滾全部回滾,無視try塊代碼的捕獲。
3. TransactionDefinition.PROPAGATION_REQUIRES_NEW
我們還是通過看代碼的方式來講述吧:第一個例子,外部沒有加事務,兩個service彼此事務獨立,外部報錯,但是兩者事務都已提交,所以都插入了:
@GetMapping("/test/add6")
public void notransaction_exception_requiresNew_requiresNew() {
User1 user1 = new User1();
user1.setName("張三");
user1Service.addRequiresNew(user1);
User2 user2 = new User2();
user2.setName("李四");
user2Service.addRequiresNew(user2);
throw new RuntimeException();
}
外部還是沒有開啟事務,user2Service報錯事務回滾,所以只有user1Service插入了。
@GetMapping("/test/add7")
public void notransaction_requiresNew_requiresNew_exception() {
User1 user1 = new User1();
user1.setName("張三");
//正常插入
user1Service.addRequiresNew(user1);
User2 user2 = new User2();
user2.setName("李四");
//保存回滾了
user2Service.addRequiresNewException(user2);
}
來看一個綜合的,外部加了REQUIRED,所以內部第一個事務和外部融合,后兩個事務獨立,在外部報錯的情況下只有addRequired回滾。李四、王五均被插入:
@GetMapping("/test/add8")
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_exception_required_requiresNew_requiresNew() {
User1 user1 = new User1();
user1.setName("張三");
//和外部事務融合,外部報錯插入被回滾
user1Service.addRequired(user1);
User2 user2 = new User2();
user2.setName("李四");
// 事務獨立,不受外部影響,正常插入
user2Service.addRequiresNew(user2);
User2 user3 = new User2();
user3.setName("王五");
// 事務獨立,不受外部影響,正常插入
user2Service.addRequiresNew(user3);
throw new RuntimeException();
}
外部加了事務,由于王五報錯被外部感知,張三的事務和外部融合,所以張三沒有被插入,這題只有李四被插入了:
@GetMapping("/test/add9")
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_required_requiresNew_requiresNew_exception() {
User1 user1 = new User1();
user1.setName("張三");
//和外部融合
user1Service.addRequired(user1);
User2 user2 = new User2();
user2.setName("李四");
//事務獨立,正常插入
user2Service.addRequiresNew(user2);
User2 user3 = new User2();
user3.setName("王五");
//報錯,插入被回滾,外部感知到了錯誤,所以張三的插入也被回滾了
user2Service.addRequiresNewException(user3);
}
王五報錯回滾,但是錯誤沒有被外部感知到,張三和外部事務融合,正常插入、李四正常插入。
@GetMapping("/test/add10")
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_required_requiresNew_requiresNew_exception_try() {
User1 user1 = new User1();
user1.setName("張三");
//正常插入
user1Service.addRequired(user1);
User2 user2 = new User2();
user2.setName("李四");
//和外部事務彼此獨立,正常插入
user2Service.addRequiresNew(user2);
User2 user3 = new User2();
user3.setName("王五");
try {
// 報錯回滾,但錯誤并沒有被外部感知,所以只有這個事務被回滾
user2Service.addRequiresNewException(user3);
} catch (Exception e) {
System.out.println("回滾");
}
}
總結: 在外圍方法開啟事務的情況下Propagation.REQUIRES_NEW修飾的內部方法依然會單獨開啟獨立事務,且與外部方法事務也獨立,內部方法之間、內部方法和外部方法事務均相互獨立,互不干擾。
4. TransactionDefinition.PROPAGATION_NESTED
代碼如下,外部沒有事務,張三、李四彼此獨立一個事務,數據均插入,外部異常不影響成功提交:
@GetMapping("/test/add11")
public void notransaction_exception_nested_nested() {
User1 user1 = new User1();
user1.setName("張三");
user1Service.addNested(user1);
User2 user2 = new User2();
user2.setName("李四");
user2Service.addNested(user2);
throw new RuntimeException();
}
同理,外部沒有事務,后者報錯不影響前者正常插入:
@GetMapping("/test/add12")
public void notransaction_nested_nested_exception() {
User1 user1 = new User1();
user1.setName("張三");
//獨立的事務,不受下方報錯影響
user1Service.addNested(user1);
User2 user2 = new User2();
user2.setName("李四");
//外部沒有事務,報錯回滾
user2Service.addNestedException(user2);
}
外部開啟事務(默認級別),內部事務與其融合,一錯全部回滾:
@GetMapping("/test/add13")
@Transactional
public void transaction_exception_nested_nested(){
//外部開啟事務,所有nest的事務都與外部事務融合,一個報錯全部回滾
User1 user1=new User1();
user1.setName("張三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addNested(user2);
throw new RuntimeException();
}
同上,外部開啟事務后內部事務與外部融合,異常能被感知后回滾了:
@GetMapping("/test/add14")
@Transactional
public void transaction_nested_nested_exception(){
User1 user1=new User1();
user1.setName("張三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addNestedException(user2);
}
異常捕獲李四的報錯自己消化了,外部不回滾,這就是transaction_nested和REQUIRED的區別:
@GetMapping("/test/add15")
@Transactional
public void transaction_nested_nested_exception_try(){
User1 user1=new User1();
user1.setName("張三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
try {
user2Service.addNestedException(user2);
} catch (Exception e) {
System.out.println("方法回滾");
}
}
總結:如果當前存在事務,則在嵌套事務內執行。如果當前沒有事務,則進行與PROPAGATION_REQUIRED類似的操作。
5.事務的幾個回滾規則
這個我們從源碼的注釋中就能看出端倪了,如下所示,注釋中已經說明了只有運行時異常或者Error可以觸發回滾,對于檢查型異常是不會回滾。
/**
* <p>By default, a transaction will be rolling back on {@link RuntimeException}
* and {@link Error} but not on checked exceptions (business exceptions). See
* org.springframework.transaction.interceptor.DefaultTransactionAttribute#rollbackOn(Throwable)
*/
Class<? extends Throwable>[] rollbackFor() default {};
那我如果要自定義一個異常使用怎么辦?如下所示即可,在注解上聲明我們需要回滾的錯誤類型即可。
@Transactional(rollbackFor= MyException.class)
6.詳解@Transactional 注解
@Transactional 作用在不同的地方會有不同的效果,我們最常見的用法就是作用于方法上,如果在方法上加該注解,就會將當前方法中的數據庫操作加入事務中。注意方法必須是public否則事務不會生效。 如果作用于類上,則意味著這個類中所有public的方法都會用到事務。接口同理,但我們不建議這么用。
它的常見參數配置如下:
- 傳播屬性(propagation):事務的傳播行為,默認值為REQUIRED,可選的值在上面介紹過
- 隔離級別(isolation):事務的隔離級別,默認值采用DEFAULT,可選的值在上面介紹過
- 回滾規則(rollbackFor):用于指定能夠觸發事務回滾的異常類型,并且可以指定多個異常類型。
- 只讀屬性(readOnly):指定事務是否為只讀事務,默認值為 false。
- 超時時間(timeout):事務的超時時間,默認值為-1(不會超時)。如果超過該時間限制但事務還沒有完成,則自動回滾事務。
7.Spring AOP自調用問題
這個問題,我們不妨舉個例子來說吧,首先我們看看下面這段代碼,很明顯如果我們直接調用add17報錯了事務會回滾,原因很簡單,這個method1加了注解,所以如果我們通過api等工具調用method1時,真正執行這段代碼的對象是結果Spring容器bpp處理過的cglib代理類:
@Transactional
@GetMapping("/test/add17")
public void method1(){
User2 user2 = new User2();
user2.setName("李四");
user2Service.insert(user2);
System.out.println(1/0);
}
好了,有了上文的鋪墊,我們再來說說嵌套調用失效問題,代碼如下所示,當我們使用接口調用工具調用時,發現method1執行出錯,李四還是被成功插入了,這是為什么呢? 原因很簡單method1執行者并不是cglib代理對象,下面這段method1,完整的代碼應該是this.method1,
@GetMapping("/test/add16")
public void add16() {
method1();
}
@Transactional
@GetMapping("/test/add17")
public void method1(){
User2 user2 = new User2();
user2.setName("李四");
user2Service.insert(user2);
System.out.println(1/0);
}
這就導致執行調用method1調用者是this,而不是cglib代理的增強類,如下圖所示,正是因為調用者不是代理,導致代理根本不知道method1被調用了,所以事務就失效了
如何解決spring自調用問題呢?
最干脆就是調用時避免嵌套使用就好了,但是有時候應該這個方法要依賴外部的處理邏輯,而外部方法又臭又長改造兩量很大導致無法重構。這時候我們只能想別的辦法。我以前解決的辦法就比較干脆了,既然問題的根源是調用對象錯誤,那我就干脆找出這個對象來調用不就解決了?
所以我們的思路是這樣的,如下代碼所示:
首先的controller中假如應用上下文:
@Autowired
private ApplicationContext applicationContext;
用這個上下文去容器中把他撈出來調用method1,問題解決
@GetMapping("/test/add16")
public void add16() {
TestController t = (TestController) applicationContext.getBean("testController");
t.method1();
}
@Transactional
@GetMapping("/test/add17")
public void method1() {
User2 user2 = new User2();
user2.setName("李四");
user2Service.insert(user2);
System.out.println(1 / 0);
}
當然這里還有一種方法,將代理的service類注入,因為spring注入的類都是經過cglib增強的類,所以使用注入的bean也能解決問題,只不過寫法很丑陋而已。
@Autowired
private TestController t;
@GetMapping("/test/add16")
public void add16() {
t.method1();
}
@Transactional
@GetMapping("/test/add17")
public void method1() {
User2 user2 = new User2();
user2.setName("李四");
user2Service.insert(user2);
System.out.println(1 / 0);
}
8.事務場景注意事項
整體大概有以下幾點:
- 正確的設置@Transactional 的rollbackFor 和propagation 屬性,否則事務可能會回滾失敗;
- 避免同一個類中調用@Transactional 注解的方法,這樣會導致事務失效
- @Transactional 注解的方法所在的類必須被Spring 管理,否則不生效;
- @Transactional 注解只有作用到public 方法上事務才生效;
- 底層使用的數據庫必須支持事務機制,否則不生效;
小結
自此我們Spring事務和設計理念和底層源碼實現并結合相應案例對此進行了深入的分析,希望對你有幫助。