原子性(atomicity)：“原子”的本意是“不可再分”，事務(wù)的原子性表現(xiàn)為一個事務(wù)中涉及到的多個操作在邏輯上缺一不可。事務(wù)的原子性要求事務(wù)中的所有操作要么都執(zhí)行，要么都不執(zhí)行。
一致性(consistency)：“一致”指的是數(shù)據(jù)的一致，具體是指：所有數(shù)據(jù)都處于滿足業(yè)務(wù)規(guī)則的一致性狀態(tài)。一致性原則要求：一個事務(wù)中不管涉及到多少個操作，都必須保證事務(wù)執(zhí)行之前數(shù)據(jù)是正確的，事務(wù)執(zhí)行之后數(shù)據(jù)仍然是正確的。如果一個事務(wù)在執(zhí)行的過程中，其中某一個或某幾個操作失敗了，則必須將其他所有操作撤銷，將數(shù)據(jù)恢復(fù)到事務(wù)執(zhí)行之前的狀態(tài)，這就是回滾。
隔離性(isolation)：在應(yīng)用程序?qū)嶋H運行過程中，事務(wù)往往是并發(fā)執(zhí)行的，所以很有可能有許多事務(wù)同時處理相同的數(shù)據(jù)，因此每個事務(wù)都應(yīng)該與其他事務(wù)隔離開來，防止數(shù)據(jù)損壞。隔離性原則要求多個事務(wù)在并發(fā)執(zhí)行過程中不會互相干擾。
持久性(durability)：持久性原則要求事務(wù)執(zhí)行完成后，對數(shù)據(jù)的修改永久的保存下來，不會因各種系統(tǒng)錯誤或其他意外情況而受到影響。通常情況下，事務(wù)對數(shù)據(jù)的修改應(yīng)該被寫入到持久化存儲器中。

1.2. 隔離級別

事務(wù)并發(fā)引起一些讀的問題：

臟讀：一個事務(wù)可以讀取另一個事務(wù)未提交的數(shù)據(jù)
不可重復(fù)讀：一個事務(wù)可以讀取另一個事務(wù)已提交的數(shù)據(jù) 單條記錄前后不匹配
虛讀（幻讀：一個事務(wù)可以讀取另一個事務(wù)已提交的數(shù)據(jù) 讀取的數(shù)據(jù)前后多了點或者少了點

并發(fā)寫：使用mysql默認的鎖機制（獨占鎖）

解決讀問題：設(shè)置事務(wù)隔離級別

read uncommitted(0)
read committed(2)
repeatable read(4)
Serializable(8)

隔離級別越高，性能越低。

一般情況下：臟讀是不可允許的，不可重復(fù)讀和幻讀是可以被適當(dāng)允許的。

1.3. 相關(guān)命令

查看全局事務(wù)隔離級別：SELECT @@global.tx_isolation

設(shè)置全局事務(wù)隔離級別：set global transaction isolation level read committed;

查看當(dāng)前會話事務(wù)隔離級別：SELECT @@tx_isolation

設(shè)置當(dāng)前會話事務(wù)隔離級別：set session transaction isolation level read committed;

查看mysql默認自動提交狀態(tài)：select @@autocommit

設(shè)置mysql默認自動提交狀態(tài)：set autocommit = 0;【不自動提交】

開啟一個事務(wù)：start transaction;

提交事務(wù)：commit

回滾事務(wù)： rollback

在事務(wù)中創(chuàng)建一個保存點：savepoint tx1

回滾到保存點：rollback to tx1

1.4. 傳播行為

事務(wù)的傳播行為不是jdbc規(guī)范中的定義。傳播行為主要針對實際開發(fā)中的問題

1567660421239

七種傳播行為：

REQUIRED 支持當(dāng)前事務(wù)，如果不存在，就新建一個

SUPPORTS 支持當(dāng)前事務(wù)，如果不存在，就不使用事務(wù)

MANDATORY 支持當(dāng)前事務(wù)，如果不存在，拋出異常

REQUIRES_NEW 如果有事務(wù)存在，掛起當(dāng)前事務(wù)，創(chuàng)建一個新的事務(wù)

NOT_SUPPORTED 以非事務(wù)方式運行，如果有事務(wù)存在，掛起當(dāng)前事務(wù)

NEVER 以非事務(wù)方式運行，如果有事務(wù)存在，拋出異常

NESTED 如果當(dāng)前事務(wù)存在，則嵌套事務(wù)執(zhí)行（嵌套式事務(wù)）

依賴于JDBC3.0提供的SavePoint技術(shù)
刪除用戶刪除訂單。在刪除訂單后，設(shè)置savePoint，執(zhí)行刪除用戶。刪除訂單和刪除用戶在同一事務(wù)中，刪除用戶失敗，事務(wù)回滾savePoint，由用戶控制視圖提交還是回滾

這七種事務(wù)傳播機制最常用的就兩種：

REQUIRED：一個事務(wù)，要么成功，要么失敗

REQUIRES_NEW：兩個不同事務(wù)，彼此之間沒有關(guān)系。一個事務(wù)失敗了不影響另一個事務(wù)

1.4.1. 偽代碼練習(xí)

傳播行為偽代碼模擬：有a,b,c,d,e等5個方法，a中調(diào)用b,c,d,e方法的傳播行為在小括號中標出

a(required){
	b(required);
	c(requires_new);
	d(required);
	e(requires_new);
	// a方法的業(yè)務(wù)
}

問題：

a方法的業(yè)務(wù)出現(xiàn)異常，會怎樣？a,b,d回滾 c,e不回滾
d方法出現(xiàn)異常，會怎樣？a,b,d回滾；c不回滾；e未執(zhí)行
e方法出現(xiàn)異常，會怎樣？a,b,d,e回滾 c不回滾，e方法出異常會上拋影響到上級方法
b方法出現(xiàn)異常，會怎樣？a,b回滾 c,d,e未執(zhí)行

加點難度：

a(required){
	b(required){
		f(requires_new);
		g(required)
	}
	c(requires_new){
		h(requires_new)
		i(required)
	}
	d(required);
	e(requires_new);
	// a方法的業(yè)務(wù)
}

問題：

a方法業(yè)務(wù)出異常？a,b,g,d回滾；f,c,h,i,e不回滾
e方法出異常？e,a,b,g,d回滾；f,c,h,i不回滾
d方法出異常？a,b,g,d回滾；f,c,h,i不回滾;e為執(zhí)行
h,i方法分別出異常?h,i,c,a,b,g回滾;f不回滾;d,e未執(zhí)行
i方法出異常？i,c,a,b,g回滾；f,h不回滾；d,e未執(zhí)行
f,g方法分別出異常？f,g,b,a回滾；c,h,i,d,e未執(zhí)行

1.4.2. 改造商品新增代碼

現(xiàn)在商品保存的方法結(jié)構(gòu)如下：

    @Override
    public void bigSave(SpuVo spuVo) {
        /// 1.保存spu相關(guān)
        // 1.1. 保存spu基本信息 spu_info
        Long spuId = saveSpu(spuVo);

        // 1.2. 保存spu的描述信息 spu_info_desc
        saveSpuDesc(spuVo, spuId);

        // 1.3. 保存spu的規(guī)格參數(shù)信息
        saveBaseAttr(spuVo, spuId);

        /// 2. 保存sku相關(guān)信息
        saveSku(spuVo, spuId);
    }

    /**
     * 保存sku相關(guān)信息及營銷信息
     * @param spuInfoVO
     */
    private void saveSku(SpuVo spuVo, Long spuId) { 。。。 }

    /**
     * 保存spu基本屬性信息
     * @param spuInfoVO
     */
    private void saveBaseAttr(SpuVo spuVo, Long spuId) { 。。。 }

    /**
     * 保存spu描述信息（圖片）
     * @param spuInfoVO
     */
    private void saveSpuDesc(SpuVo spuVo, Long spuId) { 。。。 }

    /**
     * 保存spu基本信息
     * @param spuInfoVO
     */
    private void saveSpu(SpuVo spuVo) {  。。。 }

為了測試事務(wù)傳播行為，我們在SpuInfoService接口中把saveSkuInfoWithSaleInfo、saveBaseAttrs、saveSpuDesc、saveSpuInfo聲明為service接口方法。

public interface SpuInfoService extends IService<SpuInfoEntity> {

    PageVo queryPage(QueryCondition params);

    PageVo querySpuInfo(QueryCondition condition, Long catId);

    void saveSpuInfoVO(SpuInfoVO spuInfoVO);

    void saveSku(SpuVo spuVo, Long spuId);

    void saveBaseAttr(SpuVo spuVo, Long spuId);

    void saveSpuDesc(SpuVo spuVo, Long spuId);

    Long saveSpu(SpuVo spuVo);
}

再把SpuInfoServiceImpl實現(xiàn)類的對應(yīng)方法改成public：

1584780507279

1.4.3. 測試1：同一service + requires_new

springboot 1.x使用事務(wù)需要在引導(dǎo)類上添加**@EnableTransactionManagement注解開啟事務(wù)支持**

springboot 2.x可直接使用**@Transactional**玩事務(wù)，傳播行為默認是REQUIRED

添加事務(wù)：

1584784895102

這時，在保存商品的主方法中制造異常：

1584784987731

由于保存商品描述方法使用的是requires_new，spu應(yīng)該會回滾，spu_desc應(yīng)該保存成功。

清空pms_spu_desc表，再添加一個spu保存。

結(jié)果pms_spu_desc表中依然沒有數(shù)據(jù)。

但是控制臺打印了新增pms_spu_desc表的sql語句：

1584791120439

說明saveSpuDesc方法的事務(wù)回滾了，也就是說該方法配置的事務(wù)傳播機制沒有生效。

解決方案：

把service方法放到不同的service中使用動態(tài)代理對象調(diào)用該方法

1.4.4. 測試2：不同service + requires_new

把saveSpuDesc方法放到SpuDescService中：

1584791341509

在實現(xiàn)類中實現(xiàn)該方法，可以把之前的實現(xiàn)copy過來：

1584791517742

改造SpuServiceImpl中保存商品的方法，調(diào)用SpuDescServiceImpl的saveSpuDesc方法：

1584791613579

再次重啟gmall-pms，雖然控制臺依然報錯，但是數(shù)據(jù)可以保存成功，說明沒有在一個事務(wù)中。

1567687774435

為什么測試1的事務(wù)傳播行為沒有生效，而測試2的事務(wù)傳播行為生效了？

spring的事務(wù)是聲明式事務(wù)，而聲明式事務(wù)的本質(zhì)是Spring AOP，SpringAOP的本質(zhì)是動態(tài)代理。

事務(wù)要生效必須是代理對象在調(diào)用。

測試1：通過this調(diào)用同一個service中的方法，this是指service實現(xiàn)類對象本身，不是代理對象，就相當(dāng)于方法中的代碼粘到了大方法里面，相當(dāng)于還是一個方法。

測試2：通過其他service對象（spuDescService）調(diào)用，這個service對象本質(zhì)是動態(tài)代理對象

接下來debug，打個斷點看看：

spuDescService：

1567689094127

this:

1567689136840

1.4.5. 在同一個service中使用傳播行為

只需要把測試1中的this.方法名()替換成this代理對象.方法名()即可。

問題是怎么在service中獲取當(dāng)前類的代理對象？

在類中獲取代理對象分三個步驟：

導(dǎo)入aop的場景依賴：spring-boot-starter-aop
開啟AspectJ的自動代理，同時要暴露代理對象：@EnableAspectJAutoProxy(exposeProxy=true)
獲取代理對象：SpuInfoService proxy = (SpuInfoService) AopContext.currentProxy();

具體如下：

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>

1567690207315

1567690368936

重啟后測試：先清空pms_spu_info_desc表中數(shù)據(jù)

1567690577522

表中數(shù)據(jù)新增成功，說明saveSpuDesc方法走的是自己的事務(wù)，傳播行為生效了。

debug可以看到，spuInfoService是一個代理對象。

1567690539055

1.5. 回滾策略

事務(wù)很重要的另一個特征是程序出異常時，會回滾。但并不是所有的異常都會回滾。

默認情況下的回滾策略：

運行時異常：不受檢異常，沒有強制要求try-catch，都會回滾。例如：ArrayOutOfIndex，OutofMemory，NullPointException
編譯時異常：受檢異常，必須處理，要么try-catch要么throws，都不回滾。例如：FileNotFoundException

可以通過@Transactional注解的下面幾個屬性改變回滾策略：

1567670630801

rollbackFor：指定的異常必須回滾
noRollbackFor：發(fā)生指定的異常不用回滾

1.5.1. 測試編譯時異常不回滾

在商品保存方法中制造一個編譯時異常：

1584791955821

重啟測試，注意pms_spu表中數(shù)據(jù)：

控制臺報異常：

1567691494892

pms_spu表中的數(shù)據(jù)新增成功了。

1567691611593

也就證明了編譯時異常不回滾。

1.5.2. 定制回滾策略

經(jīng)過剛才的測試，我們知道：

ArithmeticException異常（int i = 1/0）會回滾FileNotFoundException異常（new FileInputStream(“xxxx”)）不回滾

接下來我們來改變一下這個策略：

1584792095693

測試：

FileNotFoundException：在程序中添加new FileInputStream(“xxxx”)，然后測試。

1567692233983

還是id還是17，說明回滾了（回滾也會占用id=18）

ArithmeticException：在程序中添加int i = 1/0; 然后測試。

1567692364759

id是19，說明沒有回滾。

1.6. 超時事務(wù)

@Transactional注解，還有一個屬性是timeout超時時間，單位是秒。

1567692523018

timeout=3：是指第一個sql開始執(zhí)行到最后一個sql結(jié)束執(zhí)行之間的間隔時間。

即：超時時間（timeout）是指數(shù)據(jù)庫超時，不是業(yè)務(wù)超時。

改造之前商品保存方法：SpuInfoServiceImpl類中

1584792229794

重啟測試：控制臺出現(xiàn)事務(wù)超時異常

1567693383569

1.7. 只讀事務(wù)

@Transactional注解最后一個屬性是只讀事務(wù)屬性

1567693468270

如果一個方法標記為readOnly=true事務(wù)，則代表該方法只能查詢，不能增刪改。readOnly默認為false

給商品新增的事務(wù)標記為只讀事務(wù)：

1584792311622

測試：

1567693694019

到此這篇關(guān)于spring boot本地事務(wù)@Transactional參數(shù)詳解的文章就介紹到這了,更多相關(guān)spring boot事務(wù)Transactional內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: