spring事務傳播屬性和隔離級別

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點，與當前事務同步提交或回滾。 
嵌套事務一個很是重要的概念就是內層事務依賴於外層事務。外層事務失敗時，會回滾內層事務所作的動做。而內層事務操做失敗並不會引發外層事務的回滾。 

8) 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 幻像讀 
第一個數據正在查詢符合某一條件的數據，這時，另外一個事務又插入了一條符合條件的數據，第一個事務在第二次查詢符合同一條件的數據時，發現多了一條前一次查詢時沒有的數據，彷彿幻覺同樣，這就是幻像讀。

iv. 非重複度和幻像讀的區別 
非重複讀是指同一查詢在同一事務中屢次進行，因爲其餘提交事務所作的修改或刪除，每次返回不一樣的結果集，此時發生非重複讀。(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個賬戶都是有信用額度的，也就是說能夠超支，可是超支有金額限制）。不過原理是同樣的，簡單點也好說明一點，祝你好運！^_^