事務(wù)是邏輯處理原子性的保證手段，通過使用事務(wù)控制，可以極大的避免出現(xiàn)邏輯處理失敗導(dǎo)致的臟數(shù)據(jù)等問題。

事務(wù)最重要的兩個特性，是事務(wù)的傳播級別和數(shù)據(jù)隔離級別。

傳播級別定義的是事務(wù)的控制范圍，

事務(wù)隔離級別定義的是事務(wù)在數(shù)據(jù)庫讀寫方面的控制范圍。

事務(wù)的7種傳播級別：

1） PROPAGATION_REQUIRED ，默認(rèn)的spring事務(wù)傳播級別，使用該級別的特點(diǎn)是，如果上下文中已經(jīng)存在事務(wù)，那么就加入到事務(wù)中執(zhí)行，如果當(dāng)前上下文中不存在事務(wù)，則新建事務(wù)執(zhí)行。所以這個級別通常能滿足處理大多數(shù)的業(yè)務(wù)場景。

2）PROPAGATION_SUPPORTS ，從字面意思就知道，supports，支持，該傳播級別的特點(diǎn)是，如果上下文存在事務(wù)，則支持事務(wù)加入事務(wù)，如果沒有事務(wù)，則使用非事務(wù)的方式執(zhí)行。所以說，并非所有的包在transactionTemplate.execute中的代碼都會有事務(wù)支持。這個通常是用來處理那些并非原子性的非核心業(yè)務(wù)邏輯操作。應(yīng)用場景較少。

3）PROPAGATION_MANDATORY ， 該級別的事務(wù)要求上下文中必須要存在事務(wù)，否則就會拋出異常！配置該方式的傳播級別是有效的控制上下文調(diào)用代碼遺漏添加事務(wù)控制的保證手段。比如一段代碼不能單獨(dú)被調(diào)用執(zhí)行，但是一旦被調(diào)用，就必須有事務(wù)包含的情況，就可以使用這個傳播級別。

4）PROPAGATION_REQUIRES_NEW ，從字面即可知道，new，每次都要一個新事務(wù)，該傳播級別的特點(diǎn)是，每次都會新建一個事務(wù)，并且同時將上下文中的事務(wù)掛起，執(zhí)行當(dāng)前新建事務(wù)完成以后，上下文事務(wù)恢復(fù)再執(zhí)行。

這是一個很有用的傳播級別，舉一個應(yīng)用場景：現(xiàn)在有一個發(fā)送100個紅包的操作，在發(fā)送之前，要做一些系統(tǒng)的初始化、驗(yàn)證、數(shù)據(jù)記錄操作，然后發(fā)送100封紅包，然后再記錄發(fā)送日志，發(fā)送日志要求100%的準(zhǔn)確，如果日志不準(zhǔn)確，那么整個父事務(wù)邏輯需要回滾。
怎么處理整個業(yè)務(wù)需求呢？就是通過這個PROPAGATION_REQUIRES_NEW 級別的事務(wù)傳播控制就可以完成。發(fā)送紅包的子事務(wù)不會直接影響到父事務(wù)的提交和回滾。

5）PROPAGATION_NOT_SUPPORTED ，這個也可以從字面得知，not supported ，不支持，當(dāng)前級別的特點(diǎn)就是上下文中存在事務(wù)，則掛起事務(wù)，執(zhí)行當(dāng)前邏輯，結(jié)束后恢復(fù)上下文的事務(wù)。

這個級別有什么好處？可以幫助你將事務(wù)極可能的縮小。我們知道一個事務(wù)越大，它存在的風(fēng)險也就越多。所以在處理事務(wù)的過程中，要保證盡可能的縮小范圍。比如一段代碼，是每次邏輯操作都必須調(diào)用的，比如循環(huán)1000次的某個非核心業(yè)務(wù)邏輯操作。這樣的代碼如果包在事務(wù)中，勢必造成事務(wù)太大，導(dǎo)致出現(xiàn)一些難以考慮周全的異常情況。所以這個事務(wù)這個級別的傳播級別就派上用場了。用當(dāng)前級別的事務(wù)模板抱起來就可以了。

6）PROPAGATION_NEVER ，該事務(wù)更嚴(yán)格，上面一個事務(wù)傳播級別只是不支持而已，有事務(wù)就掛起，而PROPAGATION_NEVER傳播級別要求上下文中不能存在事務(wù)，一旦有事務(wù)，就拋出runtime異常，強(qiáng)制停止執(zhí)行！這個級別上輩子跟事務(wù)有仇。

7）PROPAGATION_NESTED ，字面也可知道，nested，嵌套級別事務(wù)。該傳播級別特征是，如果上下文中存在事務(wù)，則嵌套事務(wù)執(zhí)行，如果不存在事務(wù)，則新建事務(wù)。

那么什么是嵌套事務(wù)呢？很多人都不理解，我看過一些博客，都是有些理解偏差。

嵌套是子事務(wù)套在父事務(wù)中執(zhí)行，子事務(wù)是父事務(wù)的一部分，在進(jìn)入子事務(wù)之前，父事務(wù)建立一個回滾點(diǎn)，叫save point，然后執(zhí)行子事務(wù)，這個子事務(wù)的執(zhí)行也算是父事務(wù)的一部分，然后子事務(wù)執(zhí)行結(jié)束，父事務(wù)繼續(xù)執(zhí)行。重點(diǎn)就在于那個save point。看幾個問題就明了了：

如果子事務(wù)回滾，會發(fā)生什么？

父事務(wù)會回滾到進(jìn)入子事務(wù)前建立的save point，然后嘗試其他的事務(wù)或者其他的業(yè)務(wù)邏輯，父事務(wù)之前的操作不會受到影響，更不會自動回滾。

如果父事務(wù)回滾，會發(fā)生什么？

父事務(wù)回滾，子事務(wù)也會跟著回滾！為什么呢，因?yàn)楦甘聞?wù)結(jié)束之前，子事務(wù)是不會提交的，我們說子事務(wù)是父事務(wù)的一部分，正是這個道理。那么：

事務(wù)的提交，是什么情況？

是父事務(wù)先提交，然后子事務(wù)提交，還是子事務(wù)先提交，父事務(wù)再提交？答案是第二種情況，還是那句話，子事務(wù)是父事務(wù)的一部分，由父事務(wù)統(tǒng)一提交。

現(xiàn)在你再體會一下這個”嵌套“，是不是有那么點(diǎn)意思？

以上是事務(wù)的7個傳播級別，在日常應(yīng)用中，通常可以滿足各種業(yè)務(wù)需求，

但是除了傳播級別，在讀取數(shù)據(jù)庫的過程中，如果兩個事務(wù)并發(fā)執(zhí)行，那么彼此之間的數(shù)據(jù)是如何影響的呢？

這就需要了解一下事務(wù)的另一個特性：數(shù)據(jù)隔離級別

數(shù)據(jù)隔離級別分為不同的四種：

1、Serializable ：最嚴(yán)格的級別，事務(wù)串行執(zhí)行，資源消耗最大；

2、REPEATABLE READ ：保證了一個事務(wù)不會修改已經(jīng)由另一個事務(wù)讀取但未提交（回滾）的數(shù)據(jù)。避免了“臟讀取”和“不可重復(fù)讀取”的情況，但是帶來了更多的性能損失。

3、READ COMMITTED :大多數(shù)主流數(shù)據(jù)庫的默認(rèn)事務(wù)等級，保證了一個事務(wù)不會讀到另一個并行事務(wù)已修改但未提交的數(shù)據(jù)，避免了“臟讀取”。該級別適用于大多數(shù)系統(tǒng)。

4、Read Uncommitted ：保證了讀取過程中不會讀取到非法數(shù)據(jù)。
?
上面的解釋其實(shí)每個定義都有一些拗口，其中涉及到幾個術(shù)語：臟讀、不可重復(fù)讀、幻讀。
這里解釋一下：
?
臟讀 :所謂的臟讀，其實(shí)就是讀到了別的事務(wù)回滾前的臟數(shù)據(jù)。比如事務(wù)B執(zhí)行過程中修改了數(shù)據(jù)X，在未提交前，事務(wù)A讀取了X，而事務(wù)B卻回滾了，這樣事務(wù)A就形成了臟讀。
?
不可重復(fù)讀 ：不可重復(fù)讀字面含義已經(jīng)很明了了，比如事務(wù)A首先讀取了一條數(shù)據(jù)，然后執(zhí)行邏輯的時候，事務(wù)B將這條數(shù)據(jù)改變了，然后事務(wù)A再次讀取的時候，發(fā)現(xiàn)數(shù)據(jù)不匹配了，就是所謂的不可重復(fù)讀了。
?
幻讀 ：小的時候數(shù)手指，第一次數(shù)十10個，第二次數(shù)是11個，怎么回事？產(chǎn)生幻覺了？
幻讀也是這樣子，事務(wù)A首先根據(jù)條件索引得到10條數(shù)據(jù)，然后事務(wù)B改變了數(shù)據(jù)庫一條數(shù)據(jù)，導(dǎo)致也符合事務(wù)A當(dāng)時的搜索條件，這樣事務(wù)A再次搜索發(fā)現(xiàn)有11條數(shù)據(jù)了，就產(chǎn)生了幻讀。
?
一個對照關(guān)系表：
?????????????????????????????????????? Dirty reads????????? non-repeatable reads??????????? phantom reads
Serializable????????????????????????? 不會??????????????????????? 不會?????????????????????????????????????????? 不會
REPEATABLE READ???????????? 不會??????????????????????? 不會??????????????????????????????????????????? 會
READ COMMITTED???????????? 不會??????????????????????? 會??????????????????????????????????????????????? 會
Read Uncommitted???????????? 會?????????????????????????? 會??????????????????????????????????????????????? 會
?
所以最安全的，是Serializable，但是伴隨而來也是高昂的性能開銷。
另外，事務(wù)常用的兩個屬性：readonly和timeout
一個是設(shè)置事務(wù)為只讀以提升性能。
另一個是設(shè)置事務(wù)的超時時間，一般用于防止大事務(wù)的發(fā)生。還是那句話，事務(wù)要盡可能的小！

最后引入一個問題：
一個邏輯操作需要檢查的條件有20條，能否為了減小事務(wù)而將檢查性的內(nèi)容放到事務(wù)之外呢？

很多系統(tǒng)都是在DAO的內(nèi)部開始啟動事務(wù)，然后進(jìn)行操作，最后提交或者回滾。這其中涉及到代碼設(shè)計的問題。小一些的系統(tǒng)可以采用這種方式來做，但是在一些比較大的系統(tǒng)，
邏輯較為復(fù)雜的系統(tǒng)中，勢必會將過多的業(yè)務(wù)邏輯嵌入到DAO中，導(dǎo)致DAO的復(fù)用性下降。所以這不是一個好的實(shí)踐。

來回答這個問題：能否為了縮小事務(wù)，而將一些業(yè)務(wù)邏輯檢查放到事務(wù)外面？答案是：對于核心的業(yè)務(wù)檢查邏輯，不能放到事務(wù)之外，而且必須要作為分布式下的并發(fā)控制！
一旦在事務(wù)之外做檢查，那么勢必會造成事務(wù)A已經(jīng)檢查過的數(shù)據(jù)被事務(wù)B所修改，導(dǎo)致事務(wù)A徒勞無功而且出現(xiàn)并發(fā)問題，直接導(dǎo)致業(yè)務(wù)控制失敗。
所以，在分布式的高并發(fā)環(huán)境下，對于核心業(yè)務(wù)邏輯的檢查，要采用加鎖機(jī)制。
比如事務(wù)開啟需要讀取一條數(shù)據(jù)進(jìn)行驗(yàn)證，然后邏輯操作中需要對這條數(shù)據(jù)進(jìn)行修改，最后提交。
這樣的一個過程，如果讀取并驗(yàn)證的代碼放到事務(wù)之外，那么讀取的數(shù)據(jù)極有可能已經(jīng)被其他的事務(wù)修改，當(dāng)前事務(wù)一旦提交，又會重新覆蓋掉其他事務(wù)的數(shù)據(jù)，導(dǎo)致數(shù)據(jù)異常。
所以在進(jìn)入當(dāng)前事務(wù)的時候，必須要將這條數(shù)據(jù)鎖住，使用for update就是一個很好的在分布式環(huán)境下的控制手段。

一種好的實(shí)踐方式是使用編程式事務(wù)而非生命式，尤其是在較為規(guī)模的項目中。對于事務(wù)的配置，在代碼量非常大的情況下，將是一種折磨，而且人肉的方式，絕對不能避免這種問題。
將DAO保持針對一張表的最基本操作，然后業(yè)務(wù)邏輯的處理放入manager和service中進(jìn)行，同時使用編程式事務(wù)更精確的控制事務(wù)范圍。
特別注意的，對于事務(wù)內(nèi)部一些可能拋出異常的情況，捕獲要謹(jǐn)慎，不能隨便的catch Exception 導(dǎo)致事務(wù)的異常被吃掉而不能正常回滾。

Spring配置聲明式事務(wù)：

* 配置DataSource
* 配置事務(wù)管理器
* 事務(wù)的傳播特性
* 那些類那些方法使用事務(wù)

Spring配置文件中關(guān)于事務(wù)配置總是由三個組成部分，分別是DataSource、TransactionManager和代理機(jī)制這三部分，無論哪種配置方式，一般變化的只是代理機(jī)制這部分。

??? DataSource、TransactionManager這兩部分只是會根據(jù)數(shù)據(jù)訪問方式有所變化，

比如使用Hibernate進(jìn)行數(shù)據(jù)訪問 時，DataSource實(shí)際為SessionFactory，TransactionManager的實(shí)現(xiàn)為 HibernateTransactionManager。

?

根據(jù)代理機(jī)制的不同，Spring事務(wù)的配置又有幾種不同的方式：

第一種方式：每個Bean都有一個代理

第二種方式：所有Bean共享一個代理基類

第三種方式：使用攔截器

第四種方式：使用tx標(biāo)簽配置的攔截器

第五種方式：全注解

原文地址：https://blog.csdn.net/liangxw1/article/details/51197560

轉(zhuǎn)載于:https://www.cnblogs.com/hirampeng/p/9750855.html

總結(jié)

以上是生活随笔為你收集整理的spring事务介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。