spring事務傳播屬性和隔離等級__交易隔離等級

轉載自：https://www.cnblogs.com/jimmy-muyuan/p/5722708.html 1 事務的傳播屬性（Propagation）

1) REQUIRED ，這個是預設的屬性

Support a current transaction, create a new one if none exists.
如果存在一個事務，則支援當前事務。如果沒有事務則開啟一個新的事務。
被設定成這個層級時，會為每一個被調用的方法建立一個邏輯事務域。如果前面的方法已經建立了事務，那麼後面的方法支援當前的事務，如果當前沒有事務會重建立立事務。
如圖所示：

2) MANDATORY

Support a current transaction, throw an exception if none exists.支援當前事務，如果當前沒有事務，就拋出異常。

3) NEVER

Execute non-transactionally, throw an exception if a transaction exists.
以非事務方式執行，如果當前存在事務，則拋出異常。

4) NOT_SUPPORTED

Execute non-transactionally, suspend the current transaction if one exists.
以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。

5) REQUIRES_NEW

Create a new transaction, suspend the current transaction if one exists.
建立事務，如果當前存在事務，把當前事務掛起。
如圖所示：

6) SUPPORTS

Support a current transaction, execute non-transactionally if none exists.
支援當前事務，如果當前沒有事務，就以非事務方式執行。

7) NESTED

Execute within a nested transaction if a current transaction exists, behave like PROPAGATION_REQUIRED else.
支援當前事務，新增Savepoint點，與當前事務同步提交或復原。
嵌套事務一個非常重要的概念就是內層事務依賴於外層事務。外層事務失敗時，會復原內層事務所做的動作。而內層事務操作失敗並不會引起外層事務的復原。

註： PROPAGATION_NESTED 與PROPAGATION_REQUIRES_NEW的區別

它們非常 類似,都像一個嵌套事務，如果不存在一個活動的事務，都會開啟一個新的事務。使用PROPAGATION_REQUIRES_NEW時，內層事務與外層事務就像兩個獨立的事務一樣，一旦內層事務進行了提交後，外層事務不能對其進行復原。兩個事務互不影響。兩個事務不是一個真正的嵌套事務。同時它需要JTA 交易管理員的支援。
使用PROPAGATION_NESTED時，外層事務的復原可以引起內層事務的復原。而內層事務的異常並不會導致外層事務的復原，它是一個真正的嵌套事務。 2 事務的隔離等級（Isolation Level）

1) 首先說明一下事務並發引起的三種情況

i. Dirty Reads 髒讀
一個事務正在對資料進行更新操作，但是更新還未提交，另一個事務這時也來操作這組資料，並且讀取了前一個事務還未提交的資料，而前一個事務如果操作失敗進行了復原，後一個事務讀取的就是錯誤資料，這樣就造成了髒讀。

ii. Non-Repeatable Reads 不可重複讀取
一個事務多次讀取同一資料，在該事務還未結束時，另一個事務也對該資料進行了操作，而且在第一個事務兩次次讀取之間，第二個事務對資料進行了更新，那麼第一個事務前後兩次讀取到的資料是不同的，這樣就造成了不可重複讀取。

iii. Phantom Reads 幻像讀
第一個資料正在查詢符合某一條件的資料，這時，另一個事務又插入了一條合格資料，第一個事務在第二次查詢符合約一條件的資料時，發現多了一條前一次查詢時沒有的資料，彷彿幻覺一樣，這就是幻像讀。

註：非重複度和幻像讀的區別
非重複讀是指同一查詢在同一事務中多次進行，由於其他提交事務所做的修改或刪除，每次返回不同的結果集，此時發生非重複讀。(A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data. )

幻像讀是指同一查詢在同一事務中多次進行，由於其他提交事務所做的插入操作，每次返回不同的結果集，此時發生幻像讀。(A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another committed transaction has inserted additional rows that satisfy the condition. )

表面上看，區別就在於非重複讀能看見其他事務提交的修改和刪除，而幻像能看見其他事務提交的插入。

2) DEFAULT （預設）
這是一個PlatfromTransactionManager預設的隔離等級，使用資料庫預設的交易隔離等級.另外四個與JDBC的隔離等級相對應

3) READ_UNCOMMITTED （讀未提交）
這是事務最低的隔離等級，它允許另外一個事務可以看到這個事務未提交的資料。這種隔離等級會產生髒讀，不可重複讀取和幻像讀。

4) READ_COMMITTED （讀已提交）
保證一個事務修改的資料提交後才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的資料。這種交易隔離等級可以避免髒讀出現，但是可能會出現不可重複讀取和幻像讀。

5) REPEATABLE_READ （可重複讀）
這種交易隔離等級可以防止髒讀，不可重複讀取。但是可能出現幻像讀。它除了保證一個事務不能讀取另一個事務未提交的資料外，還保證了不可重複讀取

6) SERIALIZABLE（序列化）
這是花費最高代價但是最可靠的交易隔離等級。事務被處理為順序執行。除了防止髒讀，不可重複讀取外，還避免了幻像讀。

7) 隔離等級解決事務並行引起的問題
Dirty reads non-repeatable reads phantom reads
Serializable 不會 不會 不會
REPEATABLE READ 不會 不會 會
READ COMMITTED 不會 會 會
Read Uncommitted 會 會 會

事物傳播行為介紹:

@Transactional(propagation=Propagation.REQUIRED)
如果有事務, 那麼加入事務, 沒有的話建立一個(預設情況下)
@Transactional(propagation=Propagation.NOT_SUPPORTED)
容器不為這個方法開啟事務
@Transactional(propagation=Propagation.REQUIRES_NEW)
不管是否存在事務,都建立一個新的事務,原來的掛起,新的執行完畢,繼續執行老的事務
@Transactional(propagation=Propagation.MANDATORY)
必須在一個已有的事務中執行,否則拋出異常
@Transactional(propagation=Propagation.NEVER)
必須在一個沒有的事務中執行,否則拋出異常(與Propagation.MANDATORY相反)
@Transactional(propagation=Propagation.SUPPORTS)
如果其他bean調用這個方法,在其他bean中聲明事務,那就用事務.如果其他bean沒有聲明事務,那就不用事務.

事物逾時設定:
@Transactional(timeout=30) //預設是30秒

交易隔離等級:
@Transactional(isolation = Isolation.READ_UNCOMMITTED)
讀取未提交資料(會出現髒讀, 不可重複讀取) 基本不使用
@Transactional(isolation = Isolation.READ_COMMITTED)
讀取已提交資料(會出現不可重複讀取和幻讀)
@Transactional(isolation = Isolation.REPEATABLE_READ)
可重複讀(會出現幻讀)
@Transactional(isolation = Isolation.SERIALIZABLE)
序列化

MYSQL: 預設為REPEATABLE_READ層級
SQLSERVER: 預設為READ_COMMITTED

髒讀 : 一個事務讀取到另一事務未提交的更新資料
不可重複讀取 : 在同一事務中, 多次讀取同一資料返回的結果有所不同, 換句話說,
後續讀取可以讀到另一事務已提交的更新資料. 相反, “可重複讀”在同一事務中多次
讀取資料時, 能夠保證所讀資料一樣, 也就是後續讀取不能讀到另一事務已提交的更新資料
幻讀 : 一個事務讀到另一個事務已提交的insert資料

關於嵌套事物

可能大家對PROPAGATION_NESTED還不怎麼瞭解，覺得有必要再補充一下。
PROPAGATION_NESTED: 嵌套事務類型，是相對上面提到的六種情況（上面的六種應該稱為平面事務類型），打個比方我現在有一個事務主要有一下幾部分：
1，從A使用者帳戶裡面減去100元錢
2，往B使用者帳戶裡面添加100元錢
這樣看和以前不同的事務可能沒有什麼區別，那我現在有點特殊的要求就是，A使用者有3個帳戶，B使用者有2個帳戶，現在我的要求就是只要再A使用者的3個帳戶裡面任意一個減去100元，往B使用者的兩個帳戶中任意一個裡面增加100元就可以了。
一旦你有這樣的要求那嵌套事務類型就非常適合你。我們可以這樣理解，
一：將“從A使用者帳戶裡面減去100元錢” 和 “往B使用者帳戶裡面增加100元錢”我們暫時認為是一級事務操作
二：將從A使用者的3個帳戶的任意一個帳戶裡面減錢看做是“從A使用者帳戶裡面減去100元錢”這個一級事務的子事務（二級事務），同樣把後面存錢的看成是另一個的二級事務。
問題一：當二級事務被rollback一級事務會不會被rollback。
答案是不會的，二級事務的rollback只針對自己。
問題二：什麼時候這個一級事務會commit，什麼時候會被rollback呢。
我們主要看二級裡面出現的情況，當所有的二級事務被commit了並且一級事務沒有失敗的操作，那整個事務就算是一個成功的事務，這種情況整個事務會被commit。
當任意一個二級事務沒有被commit那整個事務就是失敗的，整個事務會被roolback。
還是拿上面的例子來說明吧。如果我在a的三個帳戶裡面減錢的操作都被二級事務給rollback了，也就是3個帳戶裡面都沒有減錢成功，整個事務就失敗了就會被rollback。如果A使用者帳戶三個帳戶裡面有一個可以扣錢而且B使用者的兩個帳戶裡面也有一個帳戶可以增加錢，那整個事務就算成功的，會被 commit。
看了一下覺得上面的例子好像不是很深刻，看這個情況（A使用者的3個帳戶都是有信用額度的，也就是說可以超支，但是超支有金額限制）。不過原理是一樣的，簡單點也好說明一點，祝你好運。