Spring Data JPA系列4——Spring聲明式數事務處理與多數據源支持

在大部分涉及到資料庫操作的項目裡面，事務控制、事務處理都是一個無法迴避的問題。得益於Spring框架的封裝，業務代碼中進行事務控制操作起來也很簡單，直接加個@Transactional註解即可，大大簡化了對業務代碼的侵入性。那麼對@Transactional事務註解瞭解的夠全面嗎？知道有哪些場景可能... ...

大家好，又見面了。

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

在第1篇《Spring Data JPA系列1：JDBC、ORM、JPA、Spring Data JPA，傻傻分不清楚？給你個選擇SpringDataJPA的理由！》中，我們對JPA的整體概念有了全面的瞭解。
在第2篇《Spring Data JPA系列2：快速在SpringBoot項目中熟練使用JPA》中也知曉了SpringBoot項目快速集成SpringData JPA以及快速上手使用JPA來進行基本的項目開發的技能。
在第3篇《Spring Data JPA系列3：JPA項目中核心場景與進階用法介紹》進一步的聊一下項目中使用JPA的一些高階複雜場景的實踐指導，覆蓋了主要核心的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）不含有DB操作相關，無需添加事務控制
（2）單條查詢語句，沒必要添加事務控制
（3）僅有查詢操作的多條SQL執行場景，可以添加只讀事務控制
（4）單條insert/update/delete語句，其實也不需要添加@Transactional事務處理，因為單條語句執行其實資料庫有隱性事務控制機制，如果執行失敗，是屬於SQL報錯，數據不會更新成功，自然也無需回滾。

儘可能縮小事務控制的代碼段處理範圍

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

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

也是從性能層面考慮，儘量將耗時的邏輯放到事務控制之外執行，事務內僅保留與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用法與技能探究》系列涵蓋內容：

開篇介紹 —— 《Spring Data JPA系列1：JDBC、ORM、JPA、Spring Data JPA，傻傻分不清楚？給你個選擇SpringDataJPA的理由！》

快速上手 —— 《Spring Data JPA系列2：SpringBoot集成JPA詳細教程，快速在項目中熟練使用JPA》

深度進階 —— 《Spring Data JPA系列3：JPA項目中核心場景與進階用法介紹》

可靠保障 —— 《Spring Data JPA系列4——Spring聲明式數事務處理與多數據源支持》

周邊擴展 —— 《JPA開發輔助效率提升方案介紹》

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

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

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

本文來自博客園，作者：架構悟道，歡迎關註公眾號[架構悟道]持續獲取更多乾貨，轉載請註明原文鏈接：https://www.cnblogs.com/softwarearch/p/16412487.html