Spring Data JPA系列4——Spring宣告式數事務處理與多資料來源支援

架構悟道發表於2022-06-25
Spring

大家好，又見面了。

到這裡呢，已經是本SpringData JPA系列文件的第四篇了，先來回顧下前面三篇：

本篇在前面幾篇的基礎上，再來聊一下資料庫相關操作經常會涉及的事務問題與多資料來源支援問題。

在大部分涉及到資料庫操作的專案裡面，事務控制、事務處理都是一個無法迴避的問題。得益於Spring框架的封裝，業務程式碼中進行事務控制操作起來也很簡單，直接加個@Transactional註解即可，大大簡化了對業務程式碼的侵入性。那麼對@Transactional事務註解瞭解的夠全面嗎？知道有哪些場景可能會導致@Transactional註解並不會如你預期的方式生效嗎？知道應該怎麼使用@Transactional才能保證對效能的影響最小化嗎？

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

先看下JDBC的事務處理

基於JDBC進行資料庫操作的時候，如果需要進行事務的控制與處理，整體的一個處理流程如下圖所示：

其中藍色的部分為需要開發人員去進行實現的，也即JDBC場景下的事務保護與處理，整個事務過程的處理都是需要開發人員進行關注與處理的。

按照這個流程的邏輯，寫一下對應的實現程式碼：


public void testJdbcTransactional(DataSource dataSource) {
    Connection conn = null;
    int result = 0;
    try {
        // 獲取連結
        conn = dataSource.getConnection();
        // 禁用自動事務提交，改為手動控制
        conn.setAutoCommit(false);
        // 設定事務隔離級別
        conn.setTransactionIsolation(
            TransactionIoslationLevel.READ_COMMITTED.getLevel()
        );

        // 執行SQL
        PreparedStatement ps = 
            conn.prepareStatement("insert into user (id, name) values (?, ?)");
        ps.setString(1, "123456");
        ps.setString(2, "Tom");
        result = ps.executeUpdate();

        // 執行成功，手動提交事務
        conn.commit();
    } catch (Exception e) {
        // 出現異常，手動回滾事務
        if (conn != null) {
            try {
                conn.rollback();
            } catch (Exception e) {
                // write log...
            }
        }
    } finally {
        // 執行結束，最終不管成功還是失敗，都要釋放資源，斷開連線
        try {
            if (conn != null && !conn.isClosed()) {
                conn.close();
            }
        } catch (Exception e) {
             // write log...
        }
    }
}

Spring宣告式事務處理機制

Spring資料庫事務約定處理邏輯流程如下：

對比上一章節的JDBC的事務處理，Spring場景下，事務的處理操作交給了Spring框架處理，開發人員僅需要實現自己的業務邏輯即可，大大簡化了事務方面的處理投入。

基於Spring事務機制，實現上述DB操作事務控制的程式碼，可以按照如下方式：


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

與JDBC事務實現程式碼相比，基於Spring的方式只需要新增一個@Transactional註解即可，程式碼中只需要實現業務邏輯即可，實現了事務控制機制對業務程式碼的低侵入性。

Spring支援的基於Spring AOP實現的宣告式事務功能，所謂宣告式事務，即使用@Transactional註解進行宣告標註，告訴Spring框架在什麼地方啟用資料庫事務控制能力。@Transactional註解，可以新增在類或者方法上。如果其新增在類上時，表明此類中所有的public非靜態方法都將啟用事務控制能力。

@Transactional註解說明

主要可選配置

readOnly

指定當前事務是否為一個只讀事務。設定為true標識此事務是個只讀事務，預設情況為false。

只讀事務
在多條查詢語句一起執行的場景裡面會涉及到的概念。表示在事務設定的那一刻開始，到整個事務執行結束的過程中，其他事務所提交的寫運算元據，對該事務都不可見。

舉個例子：
現在有一個複合查詢操作，包含2條SQL查詢操作：先獲取使用者表count數，再獲取使用者表中所有資料。
執行過程：

(1) 先執行完獲取使用者表count數，得到結果10
(2) 在還沒開始執行後一條語句的時候，另一個程式操作了DB並往使用者表中插入一條新資料
(3) 複合操作的第二條SQL語句，獲取使用者列表的操作被執行，返回了11條記錄

很明顯，複合操作中的兩條SQL語句獲取的資料結果無法匹配上。

為了避免此情況的發生，可以給複合查詢操作新增上只讀事務，這樣事務控制範圍內，事務外的寫操作就不可見，這樣就保證了事務內多條查詢語句執行結果的一致性。

那為什麼要設定為只讀事務、而不是常規的事務呢？
主要是從執行效率角度的考慮。因為這個裡的操作都是一些只讀操作，所以設定為只讀事務，資料庫會為只讀事務提供一些優化手段，比如不啟動回滾段、不記錄回滾log之類的。

rollbackFor & rollbackForClassName

用於指定需要回滾的特定異常型別，可以指定一個或者多個。當指定rollbackFor或者rollbackForClassName之後，方法執行邏輯中只有丟擲指定的異常型別，才會觸發事務回滾。


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

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

rollbackFor和rollbackForClassName作用相同，只是提供了2個不同的指定方法，允許執行Class型別或者ClassName字串。


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

noRollbackFor & noRollbackForClassName

用於指定不需要進行回滾的異常型別，當方法中丟擲指定型別的異常時，不進行事務回滾。

timeout

用於設定事務的超時秒數，預設值為-1，表示永不超時。

propagation

用於指定此事務對應的傳播型別。所謂的事務傳播型別，即當前已經在一個事務的上下文中時，又需要開始一個事務，這個時候來處理這個將要開啟的新事務的處理策略。

主要有7種型別的事務傳播型別：

  • REQUIRED：如果當前存在事務，則加入該事務；如果當前沒有事務，則建立一個新的事務。
  • SUPPORTS：如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續執行。
  • MANDATORY：如果當前存在事務，則加入該事務；如果當前沒有事務，則丟擲異常。
  • REQUIRES_NEW：建立一個新的事務，如果當前存在事務，則把當前事務掛起。
  • NOT_SUPPORTED：以非事務方式執行，如果當前存在事務，則把當前事務掛起。
  • NEVER：以非事務方式執行，如果當前存在事務，則丟擲異常。
  • NESTED：如果當前存在事務，則建立一個事務作為當前事務的巢狀事務來執行；如果當前沒有事務，則該取值等價於REQUIRED。

實際編碼的時候，可以通過@Transactional註解中的propagation引數來指定具體的傳播型別，取值由org.springframework.transaction.annotation.Propagation列舉類提供。如果不指定，則預設取值為Propagation.REQUIRED，也即如果當前存在事務，則加入該事務，如果當前沒有事務，則建立一個新的事務。


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

@Transactional失效場景避坑

同一個類中方法間呼叫

Spring的事務實現原理是AOP，而AOP的原理是動態代理。

在類內部方法之間相互呼叫的時候，本質上是類物件自身的呼叫，而不是使用代理物件去呼叫，也就不會觸發AOP，這樣其實Spring也就無法將事務控制的程式碼邏輯織入到呼叫程式碼流程中，所以這裡的事務控制就無法生效。

所以遇到同一個類中多個方法之間相互呼叫，且呼叫的方法需要做事務控制的時候需要特別注意下這個問題。解決方式，可以建2個不同的類，然後將方法放到兩個類中，這樣跨類呼叫，Spring事務機制就可以生效。

新增在非public方法上

如果將@Transactional註解新增在protected、private修飾的方法上，雖然程式碼不會有任何的報錯，但是實際上註解是不會生效的。

方法內部Try Catch吞掉相關異常

這個其實很容易理解，業務程式碼中將所有的異常給catch併吞掉了，等同於業務程式碼認為被捕獲的異常不需要去觸發回滾。對框架而言，因為異常被捕獲了，業務邏輯執行都在正常往下執行，所以也不會觸發異常回滾機制。


// catch了可能的異常，導致DB操作失敗的時候事務不會觸發回滾
@Transactional
public void insertUser() {
    try {
        // do something here...
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");

        // 直接吞掉了異常，這樣不會觸發事務回滾機制
    }
}

在業務處理邏輯中，如果確實需要知曉並捕獲相關處理的異常進行一些額外的業務邏輯處理，如果要保證事務回滾機制生效，最後需要往外丟擲RuntimeException異常，或者是繼承RuntimeException實現的業務自定義異常。如下：


// catch了可能的異常，對外丟擲RuntimeException或者其子類,可觸發事務回滾
@Transactional
public void insertUser() {
    try {
        // do something here...
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");

        // @Transactional沒有指定rollbackFor，所以丟擲RuntimeException或者其子類，可觸發事務回滾機制
        throw new RuntimeException(e);
    }
}

當然，如果@Transactional註解指定了rollbackFor為某個具體的異常型別，則最終需要保證異常時對外丟擲相匹配的異常型別，才可以觸發事務處理邏輯。如下：


// catch了指定異常，對外丟擲對應型別的異常,可觸發事務回滾
@Transactional(rollbackFor = DemoException.class)
public void insertUser() {
    try {
        // do something here...
        userRepository.save(user);
    } catch (Exception e) {
        log.error("failed to create user");
        // @Transactional有指定rollbackFor，丟擲異常要與rollbackFor指定異常型別一致
        throw new DemoException();
    }
}

對應資料庫引擎型別不支援事務

以MySQL資料庫而言，常見的資料庫引擎有InnoDB和Myisam等型別，但是MYISAM引擎型別是不支援事務的。所以如果建表時設定的引擎型別設定為MYISAM的話，即使程式碼裡面新增了@Transactional最終事務也不會生效的。

@Transactional使用策略

因為事務處理對效能會有一定的影響，所以事務也不是說任何地方都可以隨便新增的。對於一些效能敏感場景，需要注意幾點：

  1. 僅在必要的場合新增事務控制

（1）不含有DB操作相關，無需新增事務控制
（2）單條查詢語句，沒必要新增事務控制
（3）僅有查詢操作的多條SQL執行場景，可以新增只讀事務控制
（4）單條insert/update/delete語句，其實也不需要新增@Transactional事務處理，因為單條語句執行其實資料庫有隱性事務控制機制，如果執行失敗，是屬於SQL報錯，資料不會更新成功，自然也無需回滾。

  1. 儘可能縮小事務控制的程式碼段處理範圍

主要從效能層面考慮，事務機制，類似於併發場景的加鎖處理，範圍越大對效能影響越明顯

  1. 事務控制範圍內的業務邏輯儘可能簡單、避免非事務相關耗時處理邏輯

也是從效能層面考慮，儘量將耗時的邏輯放到事務控制之外執行，事務內僅保留與DB操作切實相關的邏輯

DataSource資料來源配置

DataSource整體情況

SpringBoot為DataSource提供了兩種最為常見的預設配置：

  • 面向TomcatT的JDBC
  • 面向Apache的DBCP

至於具體使用哪一個，主要是看專案pom.xml中引入了哪個jar了。
對於使用SpringBoot預設配置的專案而言，SpringBoot預設使用的是Tomcat容器，所以預設情況也是使用的Tomcat的JDBC的DataSource及其連線池。

看一下配置資料載入類DataSourceProperties的寫法：

所以我們的資料來源配置資訊，相關配置項需要以spring.datasource開頭，如下：


spring.datasource.url=jdbc:mysql://<ip>:<port>/vzn-demo?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&serverTimezone=Asia/Shanghai
spring.datasource.username=vzn-demo
spring.datasource.password=<password>

除了SpringBoot自帶的DataSource型別，還有一些其他三方提供的DataSource。專案開發工作中比較常用的有AliDruid DataSource，這裡也介紹下。

  • pom.xml中需要引入相關依賴

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid-spring-boot-starter</artifactId>
    <version>1.1.22</version>
</dependency>
  • application.properties中增加連線資訊配置

# 資料庫連線資訊
spring.datasource.druid.url=jdbc:mysql://<ip>:<port>/<db-name>?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&serverTimezone=Asia/Shanghai
spring.datasource.druid.username=<userName>
# 可以設定配置的密碼是否加密
spring.datasource.druid.connect-properties.config.decrypt=false
spring.datasource.druid.password=<password>

配置多資料來源

在大型的專案中，可能會涉及到服務需要同時連線多個資料庫進行資料操作的場景，這裡就會涉及到多個DataSource的配置。

舉個例子，現在有一個社交論壇服務，其發帖（Post）和評論（Comment）分別對應兩個DB，使用AliDruidDataSource的情況下，應該如何配置呢？

  • 首先配置application.properties

前面內容有提過，所有的資料來源相關配置項需要以spring.datasource開頭。而我們使用AliDruid進行多個資料來源的配置時，我們需要設定各個資料來源的若干配置都以spring.datasource.druid.{xxx}開頭。比如本例中，我們可以對發帖DB、評論DB兩個資料來源約定字首分別為spring.datasource.druid.post以及spring.datasource.druid.comment。

在application.properties中配置兩個資料來源的資訊：


# Post資料來源資訊
spring.datasource.druid.post.url=jdbc:mysql://<ip>:<port>/<db-name>?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&serverTimezone=Asia/Shanghai
spring.datasource.druid.post.username=<userName>
spring.datasource.druid.post.connect-properties.config.decrypt=false
spring.datasource.druid.post.password=<password>

# Comment資料來源資訊
spring.datasource.druid.comment.url=jdbc:mysql://<ip>:<port>/<db-name>?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&serverTimezone=Asia/Shanghai
spring.datasource.druid.comment.username=<userName>
spring.datasource.druid.comment.connect-properties.config.decrypt=false
spring.datasource.druid.comment.password=<password>
  • 其次自定義實現兩個DataSourceConfig類

接前面的例子，在application.properties中配置了兩個資料來源之後，需要實現兩個JAVA類用於讀取配置並做相關的配置處理。

針對Post資料來源：


@Configuration
@EnableTransactionManagement
@EnableConfigurationProperties(JpaProperties.class)
@EnableJpaRepositories(
        entityManagerFactoryRef="entityManagerFactoryPost",
        transactionManagerRef="transactionManagerPost", 
        basePackages = {"com.vzn.demo.post.repository"} // 設定哪些package下面的repository使用此資料來源
)
public class DataSourcePostConfig {
    @Primary
    @Bean
    @ConfigurationProperties("spring.datasource.druid.post")
    public DataSource dataSourcePost() {
        return DruidDataSourceBuilder.create().build();
    }

    @Autowired
    private DataSource dataSourcePost;

    @Primary
    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactoryPost(EntityManagerFactoryBuilder builder) {
        return builder
            .dataSource(dataSourcePost)
            .packages("com.vzn.demo.post.entity") // 設定哪些package下面的實體使用此資料來源
            .build();
    }

    @Primary
    @Bean
    public EntityManager entityManagerPost(EntityManagerFactoryBuilder builder) {
        return entityManagerFactoryPost(builder).getObject().createEntityManager();
    }

    @Autowired
    private JpaProperties jpaProperties;
    
    @Primary
    @Bean
    public PlatformTransactionManager transactionManagerPost(EntityManagerFactoryBuilder builder) {
        return new JpaTransactionManager(entityManagerFactoryPost(builder).getObject());
    }
}

針對Comment資料來源：


@Configuration
@EnableTransactionManagement
@EnableConfigurationProperties(JpaProperties.class)
@EnableJpaRepositories(
        entityManagerFactoryRef="entityManagerFactoryComment",
        transactionManagerRef="transactionManagerComment", 
        basePackages = {"com.vzn.demo.comment.repository"} // 設定哪些package下面的repository使用此資料來源
)
public class DataSourceCommentConfig {
    @Primary
    @Bean
    @ConfigurationProperties("spring.datasource.druid.comment")
    public DataSource dataSourceComment() {
        return DruidDataSourceBuilder.create().build();
    }

    @Autowired
    private DataSource dataSourceComment;

    @Primary
    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactoryComment(EntityManagerFactoryBuilder builder) {
        return builder
            .dataSource(dataSourceComment)
            .packages("com.vzn.demo.comment.entity") // 設定哪些package下面的實體使用此資料來源
            .build();
    }

    @Primary
    @Bean
    public EntityManager entityManagerComment(EntityManagerFactoryBuilder builder) {
        return entityManagerFactoryComment(builder).getObject().createEntityManager();
    }

    @Autowired
    private JpaProperties jpaProperties;
    
    @Primary
    @Bean
    public PlatformTransactionManager transactionManagerPost(EntityManagerFactoryBuilder builder) {
        return new JpaTransactionManager(entityManagerFactoryPost(builder).getObject());
    }
}

上述資料來源配置類中，有指定了不同package下面的程式碼，使用對應不同的DataSource，所以具體使用的時候與正常情況無異，按照約定將不同資料來源對應處理DAO類放到各自指定的package下即可，service層程式碼可以按照正常邏輯呼叫，無需感知DAO層的資料來源差異。當然，如果某些例外場景下，可以通過@Transactional(rollbackFor = Exception.class, transactionManager= "transactionManagerPost")這種方式顯式的指定要使用某個具體資料來源。

雖然，對於多資料來源有明確的處理與支援手段，但是多資料來源加劇了程式碼維護的難度與開發過程中的複雜度，所以筆者認為程式碼架構層面需要多一些思考與優化，可以通過微服務化拆分的方式來儘量避免出現多資料來源的場景。

小結，承上啟下

好啦，本篇內容就介紹到這裡。

通過本篇的內容，我們對Spring專案裡面的資料庫事務處理相關的概念有了一個相對全面的瞭解，也知道了一些可能導致Spring事務失效的因素。

通過前面的系列文件，我們一起對SpringData JPA從淺入深的進行了全方位的探討。正所謂“工欲善其事、必先利其器”，面對一個優秀的框架，如果再結合一些外部的工具，其實可以讓我們的開發效率與程式設計師開發過程的體驗更上一層樓的。在下一篇文件裡，我們將一起聊聊如何利用工具來讓我們的開發過程進一步的簡化。

如果對本文有自己的見解，或者有任何的疑問或建議，都可以留言，我們一起探討、共同進步。

補充

Spring Data JPA作為Spring Data中對於關係型資料庫支援的一種框架技術，屬於ORM的一種，通過得當的使用，可以大大簡化開發過程中對於資料操作的複雜度。

本文件隸屬於《Spring Data JPA用法與技能探究》系列的第4篇。本系列文件規劃對Spring Data JPA進行全方位的使用介紹，一共分為5篇文件，如果感興趣，歡迎關注交流。

《Spring Data JPA用法與技能探究》系列涵蓋內容：

我是悟道，聊技術、又不僅僅聊技術~

如果覺得有用，請點個關注，也可以關注下我的公眾號【架構悟道】，獲取更及時的更新。

期待與你一起探討，一起成長為更好的自己。

相關文章