Spring事务声明式事务 使用详解

Posted 2023-03-30 .29.

个人简介：Java领域新星创作者；阿里云技术博主、星级博主、专家博主；正在Java学习的路上摸爬滚打，记录学习的过程~
个人主页：.29.的博客
学习社区：进去逛一逛~

声明式事务

• 一、编程式事务
• 二、声明式事务
• • 🚀XML配置文件 设置
  • 🚀声明式事务的使用
• 三、声明式事务的属性
• • ⚪只读
  • ⚪超时
  • ⚪回滚策略
  • ⚪隔离等级
  • ⚪传播行为
• 四、全注解配置事务

一、编程式事务

---

事务的相关操作都需要我们自己去编写。

Connection conn = ...;
    
try 
    
    // 开启事务：关闭事务的自动提交
    conn.setAutoCommit(false);
    
    // 核心操作
    
    // 提交事务
    conn.commit();
    
catch(Exception e)
    
    // 回滚事务
    conn.rollBack();
    
finally
    
    // 释放数据库连接
    conn.close();
    

主要缺陷：

• 细节没有被屏蔽：具体操作过程中，所有细节都需要程序员自己来完成，比较繁琐。
• 代码复用性不高：如果没有有效抽取出来，每次实现功能都需要自己编写代码，代码就没有得到复用。

二、声明式事务

---

框架将事务操作固定模式的代码抽取出来，进行相关的封装。

封装起来后，我们只需要在配置文件中进行简单的配置即可完成操作，可通过注解标注来使用事务。

• 好处1：提高开发效率
• 好处2：消除了冗余的代码
• 好处3：框架会综合考虑相关领域中在实际开发环境下有可能遇到的各种问题，进行了健壮性、性能等各个方面的优化

🚀XML配置文件 设置

---

P命名空间 ：

需要新增相关的p命名空间（可直接复制）

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/context
       http://www.springframework.org/schema/context/spring-context.xsd
       http://www.springframework.org/schema/tx
       http://www.springframework.org/schema/tx/spring-tx.xsd">

相关设置：

<!--
    配置事务管理器的bean
-->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="druidDataSource"></property>
</bean>

<!--
    开启事务的注解驱动
    通过注解@Transactional所标识的方法或标识的类中所有的方法，都会被事务管理器管理事务
-->
<!-- transaction-manager属性的默认值是transactionManager，如果事务管理器bean的id正好就是这个默认值，则可以省略这个属性 -->
<tx:annotation-driven transaction-manager="transactionManager" />

🚀声明式事务的使用

---

@Transactional 注解：

我们通过 @Transactional 标签，来声明需要使用事务的位置，

@Transactional 标签 既可以声明类，也可以声明方法，

• @Transactional 标识在方法上，则只会影响该方法

• @Transactional 标识的类上，则会影响类中所有的方法

例如：

/**
 * @author .29.
 * @create 2023-02-28 21:21
 */
@Transactional  //⭐事务声明⭐
@Service        //对象生成，存入IOC容器
public class BookServiceImpl implements BookService
    
    @Autowired  //自动装备
    private BookDao bookDao;

    @Override
    public void buyBook(Integer bookId, Integer userId) 
        //查询图书的价格
        Integer price = bookDao.getPriceByBookId(bookId);
        //更新图书的库存
        bookDao.updateStock(bookId);
        //更新用户的余额
        bookDao.updateBalance(userId, price);
    

三、声明式事务的属性

---

⚪只读

使用：

@Transactional(readOnly = true)

功能:

对一个查询操作来说，如果我们把它设置成只读，就能够明确告诉数据库，这个操作不涉及写操作。这样数据库就能够针对查询操作来进行优化

注意:
对增删改操作设置只读会抛出异常：
java.sql.SQLException: Connection is read-only. Queries leading to data modification are not allowed

⚪超时

使用：

@Transactional(timeout = 3)//数字3代表时间限制三秒

功能:

事务在执行过程中，有可能因为遇到某些问题，导致程序卡住，从而长时间占用数据库资源。这大概率是因为程序运行出现了问题（可能是Java程序或mysql数据库或网络连接等等）。此时这个很可能出问题的程序应该被回滚，当事务执行超过我们设置的时间，就回滚事务，撤销它已做的操作，事务结束，释放资源。

结果:
超时回滚，抛出异常
org.springframework.transaction.TransactionTimedOutException: Transaction timed out: deadline was…

⚪回滚策略

使用：

@Transactional(rollbackFor = .class)

@Transactional(noRollbackFor = .class)

@Transactional(rollbackForClassName = 全类名)

@Transactional(noRollbackForClassName= 全类名)

功能：

声明式事务默认只针对运行时异常回滚，编译时异常不回滚。

可以通过@Transactional中相关属性设置回滚策略

 rollbackFor* :可让原本不回滚的回滚；
 noRollbascFor* :可让原本会回滚的不回滚

• rollbackFor属性：需要设置一个Class类型的对象

• rollbackForClassName属性：需要设置一个字符串类型的全类名

• noRollbackFor属性：需要设置一个Class类型的对象

• noRollbackForClassName属性：需要设置一个字符串类型的全类名

⚪隔离等级

使用：

@Transactional(isolation = Isolation.DEFAULT)//使用数据库默认的隔离级别
@Transactional(isolation = Isolation.READ_UNCOMMITTED)//读未提交
@Transactional(isolation = Isolation.READ_COMMITTED)//读已提交
@Transactional(isolation = Isolation.REPEATABLE_READ)//可重复读
@Transactional(isolation = Isolation.SERIALIZABLE)//串行化

功能：

数据库系统必须具有隔离并发运行各个事务的能力，使它们不会相互影响，避免各种并发问题。一个事务与其他事务隔离的程度称为隔离级别。SQL标准中规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性就越好，但并发性越弱。

• 读未提交：READ_UNCOMMITTED
  允许Transaction01读取Transaction02未提交的修改。

• 读已提交：READ_COMMITTED、
  要求Transaction01只能读取Transaction02已提交的修改。

• 可重复读：REPEATABLE_READ
  确保Transaction01可以多次从一个字段中读取到相同的值，即Transaction01执行期间禁止其它事务对这个字段进行更新。

• 串行化：SERIALIZABLE
  确保Transaction01可以多次从一个表中读取到相同的行，在Transaction01执行期间，禁止其它事务对这个表进行添加、更新、删除操作。可以避免任何并发问题，但性能十分低下。

 👆  隔离级别处理并发问题的能力，及数据库对其支持程度；👆

⚪传播行为

使用：
通过@Transactional中的propagation属性设置事务传播行为

@Transactional(propagation = Propagation.REQUIRED)

@Transactional(propagation = Propagation.SUPPORTS)

@Transactional(propagation = Propagation.MANDATORY)

@Transactional(propagation = Propagation.REQUIRES_NEW)

@Transactional(propagation = Propagation.NOT_SUPPORTED)

@Transactional(propagation = Propagation.NEVER)

@Transactional(propagation = Propagation.NESTED)

功能：
在service类中有a()方法和b()方法，a()方法上有事务，b()方法上也有事务，当a()方法执行过程中调用了b()方法，事务是如何传递的？合并到一个事务里？还是开启一个新的事务？这就是事务传播行为。

一共有七种传播行为：

• REQUIRED：支持当前事务，如果不存在就新建一个(默认)

• SUPPORTS：支持当前事务，如果当前没有事务，就以非事务方式执行

• MANDATORY：必须运行在一个事务中，如果当前没有事务正在发生，将抛出一个异常

• REQUIRES_NEW：开启一个新的事务，如果一个事务已经存在，则将这个存在的事务挂起

• NOT_SUPPORTED：以非事务方式运行，如果有事务存在，挂起当前事务

• NEVER：以非事务方式运行，如果有事务存在，抛出异常

• NESTED：如果当前正有一个事务在进行中，则该方法应当运行在一个嵌套式事务中。被嵌套的事务可以独立于外层事务进行提交或回滚。如果外层事务不存在，行为就像REQUIRED一样。

四、全注解配置事务

---

案 例：

配置类：

import com.alibaba.druid.pool.DruidDataSource;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;

import javax.sql.DataSource;


/**
 * @author .29.
 * @create 2023-03-01 8:36
 */
@Configuration   //标记为Spring配置类
@ComponentScan("com.haojin.spring")  //设置扫描的包
public class SpringConfig 
    @Bean  //标记存放至IOC容器中的方法
    public DataSource getDataSource()  //获取数据源对象的方法
        DruidDataSource druidDataSource = new DruidDataSource();
        //设置用于连接数据库的 用户 密码 url 驱动
        druidDataSource.setUrl("jdbc:mysql://localhost:3306/spring?characterEncoding=utf-8&useSSL=false");
        druidDataSource.setUsername("root");
        druidDataSource.setPassword("abc123");
        druidDataSource.setDriverClassName("com.mysql.cj.jdbc.Driver");
        return druidDataSource;
    

    @Bean
    public JdbcTemplate getJdbcTemplate(DataSource dataSource)  //获取JdbcTemplate对象的方法
        JdbcTemplate jdbcTemplate = new JdbcTemplate();          //JdbcTemplate是spring封装的，实现jdbc相关操作类
        jdbcTemplate.setDataSource(dataSource);                  //设置数据源
        return jdbcTemplate;
    

    @Bean
    public DataSourceTransactionManager getDataSourceTransactionManager(DataSource dataSource) //获取事务管理器的方法
        DataSourceTransactionManager dataSourceTransactionManager = new DataSourceTransactionManager(); //获取DataSourceTransactionManager对象
        dataSourceTransactionManager.setDataSource(dataSource);               //为其设置数据源对象
        return dataSourceTransactionManager;
    

测试：

import com.haojin.spring.controller.BookController;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

/**
 * @author .29.
 * @create 2023-03-01 8:48
 */
public class TxAllAnnotationTest 

    @Test
    public void test1()
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(SpringConfig.class);
        BookController bookController = context.getBean("bookController", BookController.class);
        bookController.buyBook(2,2);
    

---

Spring 事务机制详解

原文出处： 陶邦仁

Spring事务机制主要包括声明式事务和编程式事务，此处侧重讲解声明式事务，编程式事务在实际开发中得不到广泛使用，仅供学习参考。

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码。我们在使用Spring声明式事务时，有一个非常重要的概念就是事务属性。事务属性通常由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。我们在进行事务划分时，需要进行事务定义，也就是配置事务的属性。

下面分别详细讲解，事务的四种属性，仅供诸位学习参考：

Spring在TransactionDefinition接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事务管理的核心接口。

1 2 3 4 5 6

public interface TransactionDefinition { int getPropagationBehavior();//返回事务的传播行为。 int getIsolationLevel();//返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以看到本事务内的哪些数据。 int getTimeout();//返回事务必须在多少秒内完成。 boolean isReadOnly();//事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的。 }

1. TransactionDefinition接口中定义五个隔离级别：

ISOLATION_DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应；

ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。

ISOLATION_READ_COMMITTED  保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。

ISOLATION_REPEATABLE_READ  这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。

ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。

1： Dirty reads（脏读）。也就是说，比如事务A的未提交（还依然缓存）的数据被事务B读走，如果事务A失败回滚，会导致事务B所读取的的数据是错误的。
2： non-repeatable reads（数据不可重复读）。比如事务A中两处读取数据-total-的值。在第一读的时候，total是100，然后事务B就把total的数据改成200，事务A再读一次，结果就发现，total竟然就变成200了，造成事务A数据混乱。
3： phantom reads（幻象读数据），这个和non-repeatable reads相似，也是同一个事务中多次读不一致的问题。但是non-repeatable reads的不一致是因为他所要取的数据集被改变了（比如total的数据），但是phantom reads所要读的数据的不一致却不是他所要读的数据集改变，而是他的条件数据集改变。比如Select account.id where account.name=”ppgogo*”,第一次读去了6个符合条件的id，第二次读取的时候，由于事务b把一个帐号的名字由”dd”改成”ppgogo1″，结果取出来了7个数据。

2. 在TransactionDefinition接口中定义了七个事务传播行为：

（1）PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。

Java代码：

1 2 3 4 5 6 7 8 9 10 11

//事务属性 PROPAGATION_REQUIRED methodA{ …… methodB(); …… }   //事务属性 PROPAGATION_REQUIRED methodB{    …… }

使用spring声明式事务，spring使用AOP来支持声明式事务，会根据事务属性，自动在方法调用之前决定是否开启一个事务，并在方法执行之后决定事务提交或回滚事务。

单独调用methodB方法：

Java代码

1 2 3 4 5

main{   metodB();   }

相当于

Java代码

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

Main{   Connection con=null;   try{   con = getConnection();   con.setAutoCommit(false);   //方法调用   methodB();   //提交事务   con.commit();   }   Catch(RuntimeException ex){               //回滚事务   con.rollback();     }   finally{   //释放资源   closeCon();   }   }

Spring保证在methodB方法中所有的调用都获得到一个相同的连接。在调用methodB时，没有一个存在的事务，所以获得一个新的连接，开启了一个新的事务。

单独调用MethodA时，在MethodA内又会调用MethodB.

执行效果相当于：

Java代码

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

main{   Connection con = null;   try{   con = getConnection();       methodA();   con.commit();   }   catch(RuntimeException ex){   con.rollback();   }   finally{      closeCon();   }    }

调用MethodA时，环境中没有事务，所以开启一个新的事务.当在MethodA中调用MethodB时，环境中已经有了一个事务，所以methodB就加入当前事务。

（2）PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。

Java代码：

1 2 3 4 5 6 7 8 9

//事务属性 PROPAGATION_REQUIRED methodA(){   methodB(); }   //事务属性 PROPAGATION_SUPPORTS methodB(){   …… }

单纯的调用methodB时，methodB方法是非事务的执行的。当调用methdA时,methodB则加入了methodA的事务中,事务地执行。

（3）PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。

Java代码：

1 2 3 4 5 6 7 8 9

//事务属性 PROPAGATION_REQUIRED     methodA(){   methodB();                 }       //事务属性 PROPAGATION_MANDATORY     methodB(){     ……     }

当单独调用methodB时，因为当前没有一个活动的事务，则会抛出异常throw new IllegalTransactionStateException(“Transaction propagation ‘mandatory’ but no existing transaction found”);当调用methodA时，methodB则加入到methodA的事务中，事务地执行。

（4）PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。

Java代码：

1 2 3 4 5 6 7 8 9 10 11

//事务属性 PROPAGATION_REQUIRED methodA(){    doSomeThingA(); methodB(); doSomeThingB(); }   //事务属性 PROPAGATION_REQUIRES_NEW methodB(){    …… }

Java代码：

1 2 3

main(){   methodA(); }

相当于

Java代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

main(){   TransactionManager tm = null; try{   //获得一个JTA事务管理器     tm = getTransactionManager();     tm.begin();//开启一个新的事务     Transaction ts1 = tm.getTransaction();     doSomeThing();     tm.suspend();//挂起当前事务     try{       tm.begin();//重新开启第二个事务       Transaction ts2 = tm.getTransaction();       methodB();       ts2.commit();//提交第二个事务    }   Catch(RunTimeException ex){       ts2.rollback();//回滚第二个事务   }   finally{      //释放资源    }     //methodB执行完后，复恢第一个事务     tm.resume(ts1); doSomeThingB();     ts1.commit();//提交第一个事务 } catch(RunTimeException ex){    ts1.rollback();//回滚第一个事务 } finally{    //释放资源 } }

在这里，我把ts1称为外层事务，ts2称为内层事务。从上面的代码可以看出，ts2与ts1是两个独立的事务，互不相干。Ts2是否成功并不依赖于ts1。如果methodA方法在调用methodB方法后的doSomeThingB方法失败了，而methodB方法所做的结果依然被提交。而除了methodB之外的其它代码导致的结果却被回滚了。使用PROPAGATION_REQUIRES_NEW,需要使用JtaTransactionManager作为事务管理器。
（5）PROPAGATION_NOT_SUPPORTED  总是非事务地执行，并挂起任何存在的事务。使用PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作为事务管理器。（代码示例同上，可同理推出）

（6）PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常；

（7）PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行。这是一个嵌套事务,使用JDBC 3.0驱动时,仅仅支持DataSourceTransactionManager作为事务管理器。需要JDBC 驱动的java.sql.Savepoint类。有一些JTA的事务管理器实现可能也提供了同样的功能。使用PROPAGATION_NESTED，还需要把PlatformTransactionManager的nestedTransactionAllowed属性设为true;而nestedTransactionAllowed属性值默认为false;

Java代码：

1 2 3 4 5 6 7 8 9 10 11

//事务属性 PROPAGATION_REQUIRED methodA(){    doSomeThingA();    methodB();    doSomeThingB(); }   //事务属性 PROPAGATION_NESTED methodB(){   …… }

如果单独调用methodB方法，则按REQUIRED属性执行。如果调用methodA方法，相当于下面的效果：

Java代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

main(){ Connection con = null; Savepoint savepoint = null; try{    con = getConnection();    con.setAutoCommit(false);    doSomeThingA();    savepoint = con2.setSavepoint();    try{        methodB();    }catch(RuntimeException ex){       con.rollback(savepoint);    }    finally{      //释放资源   }      doSomeThingB();    con.commit(); } catch(RuntimeException ex){   con.rollback(); } finally{    //释放资源 } }

当methodB方法调用之前，调用setSavepoint方法，保存当前的状态到savepoint。如果methodB方法调用失败，则恢复到之前保存的状态。但是需要注意的是，这时的事务并没有进行提交，如果后续的代码(doSomeThingB()方法)调用失败，则回滚包括methodB方法的所有操作。

嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。

PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别:它们非常类似,都像一个嵌套事务，如果不存在一个活动的事务，都会开启一个新的事务。使用PROPAGATION_REQUIRES_NEW时，内层事务与外层事务就像两个独立的事务一样，一旦内层事务进行了提交后，外层事务不能对其进行回滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同时它需要JTA事务管理器的支持。

使用PROPAGATION_NESTED时，外层事务的回滚可以引起内层事务的回滚。而内层事务的异常并不会导致外层事务的回滚，它是一个真正的嵌套事务。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED时，需要JDBC 3.0以上驱动及1.4以上的JDK版本支持。其它的JTA TrasactionManager实现可能有不同的支持方式。

PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 “内部” 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行。

另一方面, PROPAGATION_NESTED 开始一个 “嵌套的” 事务,  它是已经存在事务的一个真正的子事务. 潜套事务开始执行时,  它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交。

由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 潜套事务也会被 commit, 这个规则同样适用于 roll back.
PROPAGATION_REQUIRED应该是我们首先的事务传播行为。它能够满足我们大多数的事务需求。