本篇内容主要讲解“Spring事务的失效场景有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Spring事务的失效场景有哪些”吧!
1、Spring事务最终依赖的数据库的事务，如果用的是mysql的话，执行引擎要是innodb;因为只有innoDB 支持事务。
2、Spring的事务是原理是aop，所以加事务所在bean是要Spring容器管理的；自己new出来的对象肯定是不行的。
3、Spring事务标签@Transactional必须注解在public方法上。private、protected、default以及finally修饰的方法或者类，以及静态方法，事务都会失效的。
4、同一个类中内部方法调用，事务会失效的。调用的是this，下图中的updateOrder上的事务会失效的。可以再定义一个service，调用service里面的updateOrder即可生效。
5、多线程调用事务是会失效的。事务是建立在同一个数据链接上，多线程可能拿到的连接不是同一个连接，所以事务是会失效的。如下图的doOtherThing()抛出了异常，想让add回滚那是不可能的。
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事务的失效场景有哪些”有了更深的了解，不妨来实际操作一番吧！这里是编程网网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
