Spring事务介绍和几种失效原因

最新推荐文章于 2023-12-09 17:22:25 发布

Honins

最新推荐文章于 2023-12-09 17:22:25 发布

阅读量461

点赞数 2

分类专栏： spring 文章标签： spring 事务事务失效

本文链接：https://blog.csdn.net/Honnyee/article/details/115119961

版权

spring 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

Spring事务介绍和失效原因

介绍

事务管理方式

在Spring中，事务有两种实现方式，分别是编程式事务管理和声明式事务管理两种方式。

编程式事务管理：编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。
声明式事务管理：建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。
声明式事务管理不需要入侵代码，通过@Transactional就可以进行事务操作，更快捷而且简单，推荐使用。

事务提交方式

默认情况下，数据库处于自动提交模式。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。
对于正常的事务管理，是一组相关的操作处于一个事务之中，因此必须关闭数据库的自动提交模式。不过，这个我们不用担心，spring会将底层连接的自动提交特性设置为false。也就是在使用spring进行事物管理的时候，spring会将是否自动提交设置为false，等价于JDBC中的 connection.setAutoCommit(false);，在执行完之后在进行提交，connection.commit(); 。

事务隔离级别

隔离级别是指若干个并发的事务之间的隔离程度。

TransactionDefinition 接口中定义了五个表示隔离级别的常量：

TransactionDefinition.ISOLATION_DEFAULT：这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
TransactionDefinition.ISOLATION_READ_UNCOMMITTED：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读，不可重复读和幻读，因此很少使用该隔离级别。比如PostgreSQL实际上并没有此级别。
TransactionDefinition.ISOLATION_READ_COMMITTED：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值。
TransactionDefinition.ISOLATION_REPEATABLE_READ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。该级别可以防止脏读和不可重复读。
TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

事务传播行为

所谓事务的传播行为是指，如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量：

TransactionDefinition.PROPAGATION_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是默认值。
TransactionDefinition.PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。
TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。
TransactionDefinition.PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
TransactionDefinition.PROPAGATION_NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

事务回滚规则

指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。
默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚。
可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。

事务常用配置

readOnly：该属性用于设置当前事务是否为只读事务，设置为true表示只读，false则表示可读写，默认值为false。例如：@Transactional(readOnly=true)；
rollbackFor：该属性用于设置需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，则进行事务回滚。例如：指定单一异常类：@Transactional(rollbackFor=RuntimeException.class)指定多个异常类：@Transactional(rollbackFor={RuntimeException.class, Exception.class})；
rollbackForClassName：该属性用于设置需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，则进行事务回滚。例如：指定单一异常类名称@Transactional(rollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional(rollbackForClassName={“RuntimeException”,”Exception”})。
noRollbackFor：该属性用于设置不需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，不进行事务回滚。例如：指定单一异常类：@Transactional(noRollbackFor=RuntimeException.class)指定多个异常类：@Transactional(noRollbackFor={RuntimeException.class, Exception.class})。
noRollbackForClassName：该属性用于设置不需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，不进行事务回滚。例如：指定单一异常类名称：@Transactional(noRollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional(noRollbackForClassName={“RuntimeException”,”Exception”})。
propagation ：该属性用于设置事务的传播行为。例如：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)。
isolation：该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置。
timeout：该属性用于设置事务的超时秒数，默认值为-1表示永不超时。

事务注意事项

要根据实际的需求来决定是否要使用事物，最好是在编码之前就考虑好，不然到以后就难以维护；
如果使用了事物，请务必进行事物测试，因为很多情况下以为事物是生效的，但是实际上可能未生效！
事物@Transactional的使用要放再类的公共(public)方法中，需要注意的是在 protected、private 方法上使用 @Transactional 注解，它也不会报错(IDEA会有提示)，但事务无效。
事物@Transactional是不会对该方法里面的子方法生效！也就是你在公共方法A声明的事物@Transactional，但是在A方法中有个子方法B和C，其中方法B进行了数据操作，但是该异常被B自己处理了，这样的话事物是不会生效的！反之B方法声明的事物@Transactional，但是公共方法A却未声明事物的话，也是不会生效的！如果想事物生效，需要将子方法的事务控制交给调用的方法，在子方法中使用rollbackFor注解指定需要回滚的异常或者将异常抛出交给调用的方法处理。一句话就是在使用事物的异常由调用者进行处理！
事物@Transactional由spring控制的时候，它会在抛出异常的时候进行回滚。如果自己使用catch捕获了处理了，是不生效的，如果想生效可以进行手动回滚或者在catch里面将异常抛出，比如throw new RuntimeException();。

使用

先看一下spring官方给的guide

https://spring.io/guides/gs/managing-transactions/

对于springboot中事务的用法比较简答，demo也很容易找到。我就暂时不贴了

读者如果想看用法实战，可在评论区留言，我会把项目放到github上

失效原因

我们在使用spring @Transactional管理事务时会遇到事务未生效的情况，这里整理一下失效原因。

一数据库不支持

我们知道数据库的核心服务是引擎storage engine,对于mysql数据库,数据引擎MyISAM是不支持事务的，InnoDB是支持的。所以需要先确认我们使用的数据库是否支持事务。

查看当前数据库支持的存储引擎

使用show engines;命令可以查看当前数据库支持的引擎：

1、查看MySQL系统当前使用的存储引擎：
　　使用SQL“show variables like ‘%storage_engine%’;”命令，可以查看MySQL系统当前使用的存储引擎：

2、查看指定数据库所有表使用的存储引擎：
　　使用“show table status from dbname;”命令，可以查看指定数据库所有表使用的存储引擎，其中“dbname”为数据库名。

需要注意的是，各个表所用的存储引擎可能是不同的！

3、查看指定表的存储引擎：

show create table tablename;

若数据库或者表的引擎不是InnoDB，请修改成InnoDB

可参考文章：https://aiezu.com/article/83.html

二方法不能被spring aop增强

基于jdk的动态代理

只有public修饰的方法能被事务增强，public static 也不行

基于cglib的动态代理

private static final修饰的方法都不行

方法使用的是哪种动态代理?

规则可以从源码中查看，是 org.springframework.aop.framework包中DefaultAopProxyFactory类

public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
		if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
			Class<?> targetClass = config.getTargetClass();
			if (targetClass == null) {
				throw new AopConfigException("TargetSource cannot determine target class: " +
						"Either an interface or a target is required for proxy creation.");
			}
			if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) {
				return new JdkDynamicAopProxy(config);
			}
			return new ObjenesisCglibAopProxy(config);
		}
		else {
			return new JdkDynamicAopProxy(config);
		}
	}

三方法调用类中其他事务方法的情况

贴下当前的 pom.xml文件

   <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.5.19.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
     <dependency>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
            <version>2.0.1</version>
        </dependency>

在当前版本下经过实际测试：

假设一个类Class中有方法 A B，A中使用this调用了方法B

情况1. A中加了注解 @Transactional，调用B，A中事务正常，异常会触发A中的事务。B加不加@Transactional，B中都有事务，且B中的异常会触发A中的回滚。

情况2. A中不加注解 @Transactional，B加了@Transactional。A中没有事务，B中也没有事务。异常不会触发A B 的回滚。

对于情况1，可能和网上一些文章说法不一样，可是这的确是我实际测试的结果。

将log4j添加如下配置可查看事务日志

        <logger name="org.springframework.transaction" level="TRACE"/>

在这里插入图片描述
当我进入没加注解声明的方法时
也会找到当前连接的事务

翻了下源码，这里TransactionManager是用ThreadLocal存储数据库连接和事务对象，证明这种情况下可以找到线程中的事务。

四事务方法中捕获了异常

事物@Transactional由spring控制的时候，它会在抛出异常的时候进行回滚。如果自己使用catch捕获了处理了，是不生效的，如果想生效可以进行手动回滚或者在catch里面将异常抛出，比如throw new RuntimeException();。

五回滚的异常类型错误

Spring的事务管理默认只对出现运行期异常(java.lang.RuntimeException及其子类)进行回滚（至于为什么spring要这么设计：因为spring认为Checked的异常属于业务的，coder需要给出解决方案而不应该直接扔该框架）

想捕获其他类型可使用注解上的 rollbackFor属性

六多线程下的事务

多线程请确保你的业务和事务入口在同一个线程里，否则事务也是不生效的。比如新开线程执行数据库操作，这样是不生效的。至于原因我在三中提到过 ThereadLocal

事务失效的原因大体可分为以上六类，还有其他原因的话原因补充。

参考：

https://www.cnblogs.com/xuwujing/p/11184162.html

Honins

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
Spring事务介绍和几种失效原因

Spring事务介绍和失效原因介绍Transaction事务管理方式在Spring中，事务有两种实现方式，分别是编程式事务管理和声明式事务管理两种方式。编程式事务管理：编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。声明式事务管理：建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目
复制链接

扫一扫