请你谈谈案例分析事务定义接口TransactionDefinition: 事务隔离级别 ,事务传播行为

1Spring事务管理

事务原本是数据库中的概念,在Dao层。但一般情况下,需要将事务提升到业务层,即Service层。这样做是为了能够使用事务的特性来管理具体的业务。

在Spring中通常可以通过以下两种方式来实现对事务的管理:
● 使用Spring的事务注解管理事务
● 使用AspectJ的AOP配置管理事务

2Spring事务管理API

Spring的事务管理,主要用到两个事务相关的接口。

2.1事务管理器接口(重点)

事务管理器是PlatformTransactionManager接口对象。其主要用于完成事务的提交、回滚,及获取事务的状态信息。

PlatformTransactionManager接口常用的实现类: DataSourceTransactionManager:使用JDBC或MyBatis进行数据库操作时使用。

Spring的回滚方式(理解): Spring事务的默认回滚方式是:发生运行时异常和error时回滚,发生受查(编译)异常时提交。不过,对于受查异常,程序员也可以手工设置其回滚方式。

回顾错误与异常(理解):
在这里插入图片描述
Throwable类是Java语言中所有错误或异常的超类。只有当对象是此类(或其子类之一)的实例时,才能通过Java虚拟机或者Java的throw语句抛出。

Error是程序在运行过程中出现的无法处理的错误,比如OutOfMemoryError、ThreadDeath、NoSuchMethodError等。当这些错误发生时,程序是无法处理(捕获或抛出)的,JVM一般会终止线程。

程序在编译和运行时出现的另一类错误称之为异常,它是JVM通知程序员的一种方式。通过这种方式,让程序员知道已经或可能出现错误,要求程序员对其进行处理。

异常分为运行时异常与编译时异常。

运行时异常,是RuntimeException类或其子类,即只有在运行时才出现的异常。如,NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException 等均属于运行时异常。这些异常由JVM抛出,在编译时不要求必须处理(捕获或抛出)。但,只要代码编写足够仔细,程序足够健壮,运行时异常是可以避免的。

受查异常,也叫编译时异常,即在代码编写时要求必须捕获或抛出的异常,若不处理,则无法通过编译。如SQLException,ClassNotFoundException,IOException等都属于受查异常。

RuntimeException及其子类以外的异常,均属于受查异常。当然,用户自定义的Exception的子类,即用户自定义的异常也属受查异常。程序员在定义异常时,只要未明确声明定义的为RuntimeException的子类,那么定义的就是受查异常。

2.2事务定义接口事务隔离级别事务传播行为(重点)

事务定义接口TransactionDefinition中定义了事务描述相关的三类常量:事务隔离级别、事务传播行为、事务默认超时时限,及对他们操作。

定义了五个事务隔离级别常量(掌握)
在这里插入图片描述
DEFAULT:采用DB默认的事务隔离级别。MySql的默认为REPEATABLE_READ; Oracle默认为READ_COMMITTED。

定义了七个事务传播行为常量(掌握)
所谓事务传播机制,也就是在事务在多个方法的调用中是如何传递的,是重新创建事务还是使用父方法的事务?父方法的回滚对子方法的事务是否有影响?这些都是可以通过事务传播机制来决定的。

事务传播行为常量都是以PROPAGATION_ 开头,形如PROPAGATION_XXX。
在这里插入图片描述

本文就测试一下这些事务传播机制的使用及异同

    <!-- 配置事物 dataSource -->
    <bean id="transactionManager"
          class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource"/>
    </bean>
    <tx:annotation-driven transaction-manager="transactionManager"/>

在这里插入图片描述

总结:大体的测试框架就如上所示,下面的测试修改主要是修改BlogServiceImpl和BlogServiceImpl2的事务传播机制@Transactional(propagation=Propagation.REQUIRED)

1)REQUIRED
定义:如果有事务则加入事务,如果没有事务,则创建一个新的(默认值)

  • 操作1:将BlogServiceImpl和BlogServiceImpl2的事务传播机制都修改为
    @Transactional(propagation=Propagation.REQUIRED)

在这里插入图片描述

  • 操作2:将BlogServiceImpl事务传播机制修改为@Transactional(propagation=Propagation.NOT_SUPPORTED),BlogServiceImpl2的仍为@Transactional(propagation=Propagation.REQUIRED)

在这里插入图片描述

  • 总结:当BlogServiceImpl提供事务的时候,BlogServiceImpl2的方法执行使用当前已有事务,不再新建事务;当BlogServiceImpl不创建事务的时候,BlogServiceImpl2的方法执行发现没有事务可用,自己新建事务;

2)NOT_SUPPORTED
定义:Spring不为当前方法开启事务,相当于没有事务

  • 操作:将BlogServiceImpl和BlogServiceImpl2的事务传播机制都
    修改为@Transactional(propagation=Propagation.NOT_SUPPORTED)

在这里插入图片描述
总结:NOT_SUPPORTED相当于没有Spring事务,每条执行语句单独执行,单独提交

3)REQUIRES_NEW
定义:不管是否存在事务,都创建一个新的事务,原来的方法挂起,新的方法执行完毕后,继续执行老的事务

  • 操作:将BlogServiceImpl事务传播机制为@Transactional(propagation=Propagation.REQUIRED),BlogServiceImpl2的为@Transactional(propagation=Propagation.REQUIRES_NEW)
    在这里插入图片描述
    总结:REQUIRES_NEW为当前方法创建一个新的事务,并且当前事务先提交,然后再提交老的事务

4)MANDATORY
定义:必须在一个已有的事务中执行,否则报错

  • 操作:将BlogServiceImpl事务传播机制修改为@Transactional(propagation=Propagation.NOT_SUPPORTED),BlogServiceImpl2的仍为@Transactional(propagation=Propagation.MANDATORY),查看是否报错
    在这里插入图片描述
    总结:MANDATORY必须在已有事务下被调用,否则报错;NOT_SUPPORTED执行数据库层面的事务操作,故当前测试中,insert方法成功执行,delete方法的抛错并不影响insert方法的执行

5)NEVER
定义:必须在一个没有的事务中执行,否则报错

  • 操作:将BlogServiceImpl事务传播机制修改为@Transactional(propagation=Propagation.REQUIRED),BlogServiceImpl2的仍为@Transactional(propagation=Propagation.NEVER),查看是否报错
    在这里插入图片描述
    6)SUPPORTS
    定义:如果其他bean调用这个方法时,其他bean声明了事务,则就用这个事务,如果没有声明事务,那就不用事务

  • 操作1:将BlogServiceImpl事务传播机制修改为@Transactional(propagation=Propagation.REQUIRED),BlogServiceImpl2的仍为@Transactional(propagation=Propagation.SUPPORTS)

在这里插入图片描述

  • 操作1:将BlogServiceImpl事务传播机制修改为@Transactional(propagation=Propagation.NOT_SUPPORTED),BlogServiceImpl2的仍为@Transactional(propagation=Propagation.SUPPORTS)
    在这里插入图片描述
    总结: SUPPORTS类型的事务传播机制,是否使用事务取决于调用方法是否有事务,如果有则直接用,如果没有则不使用事务

    7)NESTED
    定义:如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与REQUIRED类似的操作

  • 操作1:将BlogServiceImpl事务传播机制修改为@Transactional(propagation=Propagation.REQUIRED),BlogServiceImpl2的仍为@Transactional(propagation=Propagation.NESTED)

在这里插入图片描述

  • 操作2:将BlogServiceImpl事务传播机制修改为@Transactional(propagation=Propagation.NOT_SUPPORTED),BlogServiceImpl2的仍为@Transactional(propagation=Propagation.NESTED)
    在这里插入图片描述
    总结:save方法创建一个事务,则再调用delete方法时,直接在该事务的基础上创建一个嵌套事务,本质上还是同一个事务,做一次提交;save方法不创建事务,则调用delete方法时,直接创建一个新的事务,单独提交。

  • 1)REQUIRED
    当两个方法的传播机制都是REQUIRED时,如果一旦发生回滚,两个方法都会回滚

  • 2)REQUIRES_NEW
    当delete方法传播机制为REQUIRES_NEW,会开启一个新的事务,并单独提交方法,所以save方法的回滚并不影响delete方法事务提交

  • 3)NESTED
    当save方法为REQUIRED,delete方法为NESTED时,delete方法开启一个嵌套事务;
    当save方法回滚时,delete方法也会回滚;反之,如果delete方法回滚,则并不影响save方法的提交

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值