Spring事务的失效场景你知道多少

1、Spring事务最终依赖的数据库的事务,如果用的是mysql的话,执行引擎要是innodb;因为只有innoDB 支持事务。

2、Spring的事务是原理是aop,所以加事务所在bean是要Spring容器管理的;自己new出来的对象肯定是不行的。

3、Spring事务标签@Transactional必须注解在public方法上。privateprotecteddefault以及finally修饰的方法或者类,以及静态方法,事务都会失效的。

4、同一个类中内部方法调用,事务会失效的。调用的是this,下图中的updateOrder上的事务会失效的。可以再定义一个service,调用service里面的updateOrder即可生效。

Spring事务的失效场景你知道多少_第1张图片

5、多线程调用事务是会失效的。事务是建立在同一个数据链接上,多线程可能拿到的连接不是同一个连接,所以事务是会失效的。如下图的doOtherThing()抛出了异常,想让add回滚那是不可能的。

Spring事务的失效场景你知道多少_第2张图片

6、事务传播性,@Transactional注解时,是可以指定propagation参数的,扩展其配置不支持事务。

Propagation.NOT_SUPPORTED,这种类型的传播特性不支持事务,如果有事务则会抛异常。

目前只有这三种传播特性才会创建新事务:NESTED,REQUIRES_NEW,REQUIRED

7、当遇到异常,如果是RuntimeException则会回滚,其他则不行,除非自定义了@Transactional(rollbackFor = Exception.class), 这个配置仅限于 Throwable 异常类及其子类.

8、自己吞了异常,try catch了,自然也不会会滚了。

9、事务嵌套太多,导致回滚多了。如下本想会滚doOtherThing(),但如果doOtherthing抛出异常了,add也接收到了,也会回滚的。比较好的做法是在roleService.doOtherThing()抓住异常。

Spring事务的失效场景你知道多少_第3张图片

总结

本篇文章就到这里了,希望能够给你带来帮助,也希望您能够多多关注脚本之家的更多内容! 

你可能感兴趣的:(Spring事务的失效场景你知道多少)