引言

在大部分涉及到數(shù)據(jù)庫(kù)操作的項(xiàng)目里面，事務(wù)控制、事務(wù)處理都是一個(gè)無法回避的問題。比如，需要對(duì)SQL執(zhí)行過程進(jìn)行事務(wù)的控制與處理的時(shí)候，其整體的處理流程會(huì)是如下的示意：

首先是要開啟事務(wù)、然后執(zhí)行具體SQL，如果執(zhí)行異常則回滾事務(wù)，否則提交事務(wù)，最后關(guān)閉事務(wù)，完成整個(gè)處理過程。按照這個(gè)流程的邏輯，寫一下對(duì)應(yīng)的實(shí)現(xiàn)代碼：

public void testJdbcTransactional(DataSource dataSource) {
    Connection conn = null;
    int result = 0;
    try {
        // 獲取鏈接
        conn = dataSource.getConnection();
        // 禁用自動(dòng)事務(wù)提交，改為手動(dòng)控制
        conn.setAutoCommit(false);
        // 設(shè)置事務(wù)隔離級(jí)別
        conn.setTransactionIsolation(
            TransactionIoslationLevel.READ_COMMITTED.getLevel()
        );
        // 執(zhí)行SQL
        PreparedStatement ps = 
            conn.prepareStatement("insert into user (id, name) values (?, ?)");
        ps.setString(1, "123456");
        ps.setString(2, "Tom");
        result = ps.executeUpdate();
        // 執(zhí)行成功，手動(dòng)提交事務(wù)
        conn.commit();
    } catch (Exception e) {
        // 出現(xiàn)異常，手動(dòng)回滾事務(wù)
        if (conn != null) {
            try {
                conn.rollback();
            } catch (Exception e) {
                // write log...
            }
        }
    } finally {
        // 執(zhí)行結(jié)束，最終不管成功還是失敗，都要釋放資源，斷開連接
        try {
            if (conn != null && !conn.isClosed()) {
                conn.close();
            }
        } catch (Exception e) {
             // write log...
        }
    }
}

不難發(fā)現(xiàn)，上面大段的代碼邏輯并不復(fù)雜，對(duì)于業(yè)務(wù)而言其實(shí)僅僅只是執(zhí)行了一個(gè)insert操作而。但是雜糅的事務(wù)控制代碼，顯然干擾了業(yè)務(wù)自身的代碼處理邏輯的閱讀與理解。

常規(guī)項(xiàng)目的代碼中，涉及到DB處理的場(chǎng)景很多，如果每個(gè)地方都有這么一段事務(wù)控制的邏輯，那么整體代碼的可維護(hù)性將會(huì)比較差，想想都令人窒息。

好在，JAVA中很多項(xiàng)目現(xiàn)在都是基于Spring框架進(jìn)行構(gòu)建的。得益于 Spring框架的封裝，業(yè)務(wù)代碼中進(jìn)行事務(wù)控制操作起來也很簡(jiǎn)單，直接加個(gè) @Transactional注解即可，大大簡(jiǎn)化了對(duì)業(yè)務(wù)代碼的侵入性。那么對(duì) @Transactional事務(wù)注解了解的夠全面嗎？知道有哪些場(chǎng)景可能會(huì)導(dǎo)致 @Transactional注解并不會(huì)如你預(yù)期的方式生效嗎？知道應(yīng)該怎么使用 @Transactional才能保證對(duì)性能的影響最小化嗎？

下面我們一起探討下這些問題。

Spring聲明式事務(wù)處理機(jī)制

為了簡(jiǎn)化業(yè)務(wù)開發(fā)場(chǎng)景對(duì)事務(wù)的處理復(fù)雜度，讓開發(fā)人員可以更關(guān)注于業(yè)務(wù)自身的處理邏輯，Spring提供了聲明式事務(wù)的能力支持。

Spring數(shù)據(jù)庫(kù)事務(wù)約定處理邏輯流程如下圖所示，對(duì)比前面示例中基于JDBC的事務(wù)處理，Spring的事務(wù)的處理操作交給了Spring框架處理，開發(fā)人員僅需要實(shí)現(xiàn)自己的業(yè)務(wù)邏輯即可，大大簡(jiǎn)化了事務(wù)方面的處理投入。

基于Spring事務(wù)機(jī)制，實(shí)現(xiàn)上述DB操作事務(wù)控制的代碼，我們的代碼會(huì)變得非常的簡(jiǎn)潔：

@Transactional
public void insertUser() {
    userDao.insertUser();
}

與JDBC事務(wù)實(shí)現(xiàn)代碼相比，基于Spring的方式只需要添加一個(gè) @Transactional注解即可，代碼中只需要實(shí)現(xiàn)業(yè)務(wù)邏輯即可，實(shí)現(xiàn)了事務(wù)控制機(jī)制對(duì)業(yè)務(wù)代碼的低侵入性。

Spring支持的基于 Spring AOP實(shí)現(xiàn)的聲明式事務(wù)功能，所謂聲明式事務(wù)，即使用@Transactional注解進(jìn)行聲明標(biāo)注，告訴Spring框架在什么地方啟用數(shù)據(jù)庫(kù)事務(wù)控制能力。@Transactional注解，可以添加在類或者方法上。如果其添加在類上時(shí)，表明此類中所有的public非靜態(tài)方法都將啟用事務(wù)控制能力。

既然@Transactional注解承載了Spring框架對(duì)于事務(wù)處理的相關(guān)能力，那么接下來我們就一起看下該注解的一些可選配置以及具體使用場(chǎng)景。

@Transactional主要可選配置

只讀事務(wù)配置

通過readonly參數(shù)指定當(dāng)前事務(wù)是否為一個(gè)只讀事務(wù)。設(shè)置為true標(biāo)識(shí)此事務(wù)是個(gè)只讀事務(wù)，默認(rèn)情況為false。

@Transactional(readOnly = true)
public DomResponse<CiCdItemDetail> queryCicdItemDetail(String appCode) {
    return null;
}

這里涉及一個(gè)概念，叫做只讀事務(wù)，其含義描述如下：

在多條查詢語句一起執(zhí)行的場(chǎng)景里面會(huì)涉及到的概念。表示在事務(wù)設(shè)置的那一刻開始，到整個(gè)事務(wù)執(zhí)行結(jié)束的過程中，其他事務(wù)所提交的寫操作數(shù)據(jù)，對(duì)該事務(wù)都不可見。

舉個(gè)例子：

現(xiàn)在有一個(gè)復(fù)合查詢操作，包含2條SQL查詢操作：先獲取用戶表count數(shù)，再獲取用戶表中所有數(shù)據(jù)。

(1) 先執(zhí)行完獲取用戶表count數(shù)，得到結(jié)果10

(2) 在還沒開始執(zhí)行后一條語句的時(shí)候，另一個(gè)進(jìn)程操作了DB并往用戶表中插入一條新數(shù)據(jù)

(3) 復(fù)合操作的第二條SQL語句，獲取用戶列表的操作被執(zhí)行，返回了11條記錄

很明顯，復(fù)合操作中的兩條SQL語句獲取的數(shù)據(jù)結(jié)果無法匹配上。原因就是非原子性操作導(dǎo)致，即2條查詢操作執(zhí)行的間隔內(nèi)，有另一個(gè)寫操作修改了目標(biāo)讀取的數(shù)據(jù)，導(dǎo)致了此問題的出現(xiàn)。

為了避免此情況的發(fā)生，可以給復(fù)合查詢操作添加上只讀事務(wù)，這樣事務(wù)控制范圍內(nèi)，事務(wù)外的寫操作就不可見，這樣就保證了事務(wù)內(nèi)多條查詢語句執(zhí)行結(jié)果的一致性。

那為什么要設(shè)置為只讀事務(wù)、而不是常規(guī)的事務(wù)呢？主要是從執(zhí)行效率角度的考慮。因?yàn)檫@個(gè)里的操作都是一些只讀操作，所以設(shè)置為只讀事務(wù)，數(shù)據(jù)庫(kù)會(huì)為只讀事務(wù)提供一些優(yōu)化手段，比如不啟動(dòng)回滾段、不記錄回滾log之類的。

回滾條件設(shè)定

@Transactional有提供4個(gè)不同屬性，可以支持傳入不同的參數(shù)，設(shè)定需要回滾的條件：

其中，rollbackFor支持指定單個(gè)或者多個(gè)異常類型，只要拋出指定類型的異常，事務(wù)都將被回滾掉：

// 指定單個(gè)異常
@Transactional(rollbackFor = DemoException.class)
public void insertUser() {
    // do something here
}
// 指定多個(gè)異常
@Transactional(rollbackFor = {DemoException.class, DemoException2.class})
public void insertUser2() {
    // do something here
}

rollbackFor和rollbackForClassName作用相同，只是提供了2個(gè)不同的指定方法，允許執(zhí)行Class類型或者ClassName字符串。

// 指定異常名稱
@Transactional(rollbackForClassName = {"DemoException"})
public void insertUser() {
    // do something here
}

同理，noRollbackFor和noRollbackForClassName的使用與上面示意的相似，只是其含義功能點(diǎn)是相反的。

事務(wù)傳播行為

propagation用于指定此事務(wù)對(duì)應(yīng)的傳播類型。所謂的事務(wù)傳播類型，即當(dāng)前已經(jīng)在一個(gè)事務(wù)的上下文中時(shí)，又需要開始一個(gè)事務(wù)，這個(gè)時(shí)候來處理這個(gè)將要開啟的新事務(wù)的處理策略。

主要有7種類型的事務(wù)傳播類型：

事務(wù)的傳播行為，將會(huì)影響到事務(wù)控制的結(jié)果，比如最終是在同一事務(wù)中，一旦遇到異常，所有操作都會(huì)被回滾掉，而如果是在多個(gè)事務(wù)中，則某一個(gè)事務(wù)的回滾，不影響已提交的其余事務(wù)的回滾。

實(shí)際編碼的時(shí)候，可以通過@Transactional注解中的 propagation參數(shù)來指定具體的傳播類型，取值由 org.springframework.transaction.annotation.Propagation枚舉類提供。如果不指定，則默認(rèn)取值為 Propagation.REQUIRED，也即如果當(dāng)前存在事務(wù)，則加入該事務(wù)，如果當(dāng)前沒有事務(wù)，則創(chuàng)建一個(gè)新的事務(wù)。

/**
 * The transaction propagation type.
 * <p>Defaults to {@link Propagation#REQUIRED}.
 * @see org.springframework.transaction.interceptor.TransactionAttribute#getPropagationBehavior()
 */
Propagation propagation() default Propagation.REQUIRED;

事務(wù)超時(shí)設(shè)定

可以使用timeout屬性來設(shè)置事務(wù)的超時(shí)秒數(shù)，默認(rèn)值為-1，表示永不超時(shí)。

@Transactional失效場(chǎng)景避坑

同一個(gè)類中方法間調(diào)用

Spring的事務(wù)實(shí)現(xiàn)原理是AOP，而AOP的原理是動(dòng)態(tài)代理。

在類內(nèi)部方法之間相互調(diào)用的時(shí)候，本質(zhì)上是類對(duì)象自身的調(diào)用，而不是使用代理對(duì)象去調(diào)用，也就不會(huì)觸發(fā)AOP，這樣其實(shí)Spring也就無法將事務(wù)控制的代碼邏輯織入到調(diào)用代碼流程中，所以這里的事務(wù)控制就無法生效。

public void insertUser() {
    writeDataIntoDb();
}
@Transactional
public void writeDataIntoDb() {
  // ...
}

所以遇到同一個(gè)類中多個(gè)方法之間相互調(diào)用，且調(diào)用的方法需要做事務(wù)控制的時(shí)候需要特別注意下這個(gè)問題。解決方式，可以建2個(gè)不同的類，然后將方法放到兩個(gè)類中，這樣跨類調(diào)用，Spring事務(wù)機(jī)制就可以生效。

添加在非public方法上

如果將@Transactional注解添加在protected、private修飾的方法上，雖然代碼不會(huì)有任何的報(bào)錯(cuò)，但是實(shí)際上注解是不會(huì)生效的。

@Transactional
private void writeDataIntoDb() {
  // ...
}

方法內(nèi)部Try Catch吞掉相關(guān)異常

這個(gè)其實(shí)很容易理解，業(yè)務(wù)代碼中將所有的異常給catch并吞掉了，等同于業(yè)務(wù)代碼認(rèn)為被捕獲的異常不需要去觸發(fā)回滾。對(duì)框架而言，因?yàn)楫惓１徊东@了，業(yè)務(wù)邏輯執(zhí)行都在正常往下運(yùn)行，所以也不會(huì)觸發(fā)異常回滾機(jī)制。

// catch了可能的異常，導(dǎo)致DB操作失敗的時(shí)候事務(wù)不會(huì)觸發(fā)回滾
@Transactional
public void insertUser() {
    try {
        UserEntity user = new UserEntity();
        user.setWorkId("123456");
        user.setUserName("王小二");
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");
        // 直接吞掉了異常，這樣不會(huì)觸發(fā)事務(wù)回滾機(jī)制
    }
}

在業(yè)務(wù)處理邏輯中，如果確實(shí)需要知曉并捕獲相關(guān)處理的異常進(jìn)行一些額外的業(yè)務(wù)邏輯處理，如果要保證事務(wù)回滾機(jī)制生效，最后需要往外拋出 RuntimeException異常，或者是繼承RuntimeException實(shí)現(xiàn)的業(yè)務(wù)自定義異常。如下：

// catch了可能的異常，對(duì)外拋出RuntimeException或者其子類,可觸發(fā)事務(wù)回滾
@Transactional
public void insertUser() {
    try {
        UserEntity user = new UserEntity();
        user.setWorkId("123456");
        user.setUserName("王小二");
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");
        // @Transactional沒有指定rollbackFor，所以拋出RuntimeException或者其子類，可觸發(fā)事務(wù)回滾機(jī)制
        throw new RuntimeException(e);
    }
}

當(dāng)然，如果@Transactional注解指定了 rollbackFor為某個(gè)具體的異常類型，則最終需要保證異常時(shí)對(duì)外拋出相匹配的異常類型，才可以觸發(fā)事務(wù)處理邏輯。如下：

// catch了指定異常，對(duì)外拋出對(duì)應(yīng)類型的異常,可觸發(fā)事務(wù)回滾
@Transactional(rollbackFor = DemoException.class)
public void insertUser() {
    try {
        UserEntity user = new UserEntity();
        user.setWorkId("123456");
        user.setUserName("王小二");
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");
        // @Transactional有指定rollbackFor，拋出異常要與rollbackFor指定異常類型一致
        throw new DemoException();
    }
}

對(duì)應(yīng)數(shù)據(jù)庫(kù)引擎類型不支持事務(wù)

以MySQL數(shù)據(jù)庫(kù)而言，常見的數(shù)據(jù)庫(kù)引擎有 InnoDB和 Myisam等類型，但是MYISAM引擎類型是不支持事務(wù)的。所以如果建表時(shí)設(shè)置的引擎類型設(shè)置為 MYISAM的話，即使代碼里面添加了@Transactional最終事務(wù)也不會(huì)生效的。

@Transactional使用策略

因?yàn)槭聞?wù)處理對(duì)性能會(huì)有一定的影響，所以事務(wù)也不是說任何地方都可以隨便添加的。對(duì)于一些性能敏感場(chǎng)景，需要注意幾點(diǎn)：

• 僅在必要的場(chǎng)合添加事務(wù)控制

（1）不含有DB操作相關(guān)，無需添加事務(wù)控制

（2）單條查詢語句，沒必要添加事務(wù)控制

（3）僅有查詢操作的多條SQL執(zhí)行場(chǎng)景，可以添加只讀事務(wù)控制

（4）單條 insert/update/delete語句，其實(shí)也不需要添加 @Transactional事務(wù)處理，因?yàn)閱螚l語句執(zhí)行其實(shí)數(shù)據(jù)庫(kù)有隱性事務(wù)控制機(jī)制，如果執(zhí)行失敗，是屬于 SQL報(bào)錯(cuò)，數(shù)據(jù)不會(huì)更新成功，自然也無需回滾。

• 盡可能縮小事務(wù)控制的代碼段處理范圍
• 主要從性能層面考慮，事務(wù)機(jī)制，類似于并發(fā)場(chǎng)景的加鎖處理，范圍越大對(duì)性能影響越明顯
• 事務(wù)控制范圍內(nèi)的業(yè)務(wù)邏輯盡可能簡(jiǎn)單、避免非事務(wù)相關(guān)耗時(shí)處理邏輯
• 也是從性能層面考慮，盡量將耗時(shí)的邏輯放到事務(wù)控制之外執(zhí)行，事務(wù)內(nèi)僅保留與DB操作切實(shí)相關(guān)的邏輯

總結(jié)

好啦，關(guān)于Spring中事務(wù)控制的相關(guān)用法，以及@Transactional使用過程中可能的一些失效場(chǎng)景，就探討到這里了。那么你對(duì)事務(wù)這塊有哪些自己的理解呢？

更多關(guān)于Spring事務(wù)@Transactional失效的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論