終於等到了B站的薪資溝通電話，美滋滋，本節開始進入Spring資料訪問篇，講解spring事務，文章參考自Tom老師視訊。

事務基本概念

事務(Transaction)是訪問並可能更新資料庫中各種資料項的一個程式執行單元(unit)。

特點：

事務是恢復和併發控制的基本單位。

事務應該具有4個屬性：原子性、一致性、隔離性、永續性。這四個屬性通常稱為ACID特性。

原子性（atomicity）。一個事務是一個不可分割的工作單位，事務中包括的諸操作要麼都做，要麼都不做。

一致性（consistency）。事務必須是使資料庫從一個一致性狀態變到另一個一致性狀態。一致性與原子性是密切相關的。

隔離性（isolation）。一個事務的執行不能被其他事務干擾。即一個事務內部的操作及使用的資料對併發的其他事務是隔離的，併發執行的各個事務之間不能互相干擾。

永續性（durability）。永續性也稱永久性（permanence），指一個事務一旦提交，它對資料庫中資料的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。

事務的基本原理

Spring事務的本質其實就是資料庫對事務的支援，沒有資料庫的事務支援，spring是無法提供事務功能的。對於純JDBC操作資料庫，想要用到事務，可以按照以下步驟進行：

獲取連線Connection con=DriverManager.getConnection();

開啟事務con.setAutoCommit(true/false);

執行CRUD

提交事務/回滾事務con.commit()/con.rollback();

關閉連線conn.close();

使用Spring的事務管理功能後，我們可以不再寫步驟2和4的程式碼，而是由Spirng自動完成。

那麼Spring是如何在我們書寫的CRUD之前和之後開啟事務和關閉事務的呢？解決這個問題，也就可以從整體上理解Spring的事務管理實現原理了。下面簡單地介紹下，以註解方式為例子

配置檔案開啟註解驅動，在相關的類和方法上通過註解@Transactional標識。

spring在啟動的時候會去解析生成相關的bean，這時候會檢視擁有相關注解的類和方法，並且為這些類和方法生成代理，並根據@Transaction的相關引數進行相關配置注入，這樣就在代理中為我們把相關的事務處理掉了（開啟正常提交事務，異常回滾事務）。

真正的資料庫層的事務提交和回滾是通過binlog或者redolog實現的。

Spring事務的傳播屬性

所謂spring事務的傳播屬性，就是定義在存在多個事務同時存在的時候，spring應該如何處理這些事務的行為。這些屬性在TransactionDefinition中定義，具體常量的解釋見下表：

資料庫隔離級別

髒讀：一事務對資料進行了增刪改，但未提交，另一事務可以讀取到未提交的資料。如果第一個事務這時候回滾了，那麼第二個事務就讀到了髒資料。

不可重複讀：一個事務中發生了兩次讀操作，第一次讀操作和第二次操作之間，另外一個事務對資料進行了修改，這時候兩次讀取的資料是不一致的。

幻讀：第一個事務對一定範圍的資料進行批量修改，第二個事務在這個範圍增加一條資料，這時候第一個事務就會丟失對新增資料的修改。

總結：

隔離級別越高，越能保證資料的完整性和一致性，但是對併發效能的影響也越大。

大多數的資料庫預設隔離級別為ReadCommited，比如SqlServer、Oracle

少數資料庫預設隔離級別為：RepeatableRead比如：MySQL、InnoDB

Spring中的隔離級別

事務的巢狀

通過上面的理論知識的鋪墊，我們大致知道了資料庫事務和spring事務的一些屬性和特點，接下來我們通過分析一些巢狀事務的場景，來深入理解spring事務傳播的機制。

假設外層事務ServiceA的MethodA()呼叫內層ServiceB的MethodB()

PROPAGATION_REQUIRED(spring預設)

如果ServiceB.MethodB()的事務級別定義為PROPAGATION_REQUIRED，那麼執行ServiceA.MethodA()的時候spring已經起了事務，這時呼叫ServiceB.MethodB()，ServiceB.MethodB()看到自己已經執行在ServiceA.MethodA()的事務內部，就不再起新的事務。假如ServiceB.MethodB()執行的時候發現自己沒有在事務中，他就會為自己分配一個事務。

這樣，在ServiceA.MethodA()或者在ServiceB.MethodB()內的任何地方出現異常，事務都會被回滾。

PROPAGATION_REQUIRES_NEW

比如我們設計ServiceA.MethodA()的事務級別為PROPAGATION_REQUIRED，ServiceB.MethodB()的事務級別為PROPAGATION_REQUIRES_NEW。那麼當執行到ServiceB.MethodB()的時候，ServiceA.MethodA()所在的事務就會掛起，ServiceB.MethodB()會起一個新的事務，等待ServiceB.MethodB()的事務完成以後，它才繼續執行。

他與PROPAGATION_REQUIRED的事務區別在於事務的回滾程度了。因為ServiceB.MethodB()是新起一個事務，那麼就是存在兩個不同的事務。如果ServiceB.MethodB()已經提交，那麼ServiceA.MethodA()失敗回滾，ServiceB.MethodB()是不會回滾的。如果ServiceB.MethodB()失敗回滾，如果他丟擲的異常被ServiceA.MethodA()捕獲，ServiceA.MethodA()事務仍然可能提交(主要看B丟擲的異常是不是A會回滾的異常)。

PROPAGATION_SUPPORTS

假設ServiceB.MethodB()的事務級別為PROPAGATION_SUPPORTS，那麼當執行到ServiceB.MethodB()時，如果發現ServiceA.MethodA()已經開啟了一個事務，則加入當前的事務，如果發現ServiceA.MethodA()沒有開啟事務，則自己也不開啟事務。這種時候，內部方法的事務性完全依賴於最外層的事務。

PROPAGATION_NESTED

現在的情況就變得比較複雜了,ServiceB.MethodB()的事務屬性被配置為PROPAGATION_NESTED,此時兩者之間又將如何協作呢?ServiceB#MethodB如果rollback,那麼內部事務(即ServiceB#MethodB)將回滾到它執行前的SavePoint而外部事務(即ServiceA#MethodA)可以有以下兩種處理方式:

捕獲異常，執行異常分支邏輯

這種方式也是巢狀事務最有價值的地方,它起到了分支執行的效果,如果ServiceB.MethodB失敗,那麼執行ServiceC.MethodC(),而ServiceB.MethodB已經回滾到它執行之前的SavePoint,所以不會產生髒資料(相當於此方法從未執行過),這種特性可以用在某些特殊的業務中,而PROPAGATION_REQUIRED和PROPAGATION_REQUIRES_NEW都沒有辦法做到這一點。

b、外部事務回滾/提交程式碼不做任何修改,那麼如果內部事務(ServiceB#MethodB)rollback,那麼首先ServiceB.MethodB回滾到它執行之前的SavePoint(在任何情況下都會如此),外部事務(即ServiceA#MethodA)將根據具體的配置決定自己是commit還是rollback另外三種事務傳播屬性基本用不到，在此不做分析。

Spring事務API架構圖