transactional注解的使用_@Transactional 失效的场景

@Transactional 注解应该大家在开发过程中使用过了，但大家是否碰到过其失效的情况呢？我这边大概整理下失效产生的情况。

事务分类

Spring提供了很好事务管理机制，分为编程式事务和声明式事务。

编程式事务：需要手动在代码中管理事务的提交、回滚等操作。

声明式事务：基于AOP将具体业务与事务处理解耦。可以有基于TX和AOP的xml配置文件方式以及基于@Transactional注解的方式。这边主要介绍@Transactional注解的方式

@Transactional失效场景

1、@Transactional注解应用在非public 修饰的方法上，Transactional将会失效。

Spring 有一段描述关于方法可见性：

@Transactional注解只对代理类时的public方法有效，被protected、private、package-visible修饰的方法使用@Transactional注解无效。

2、检查异常是不是unchecked异常。

Spring默认继承自 RuntimeException 的异常；其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定 rollbackFor属性。

3、一个类中方法调用，内部方法为@Transactional不起作用。

4、数据库引擎不支持事务，MySQL数据库innodb引擎支持事务，当引擎换成myisam那就不能支持事务了。

5、@Transactional的方法中，出现异常为抛出，导致失效。

事务的参数配置

Propagation枚举了多种事务传播模式，部分列举如下：

1、REQUIRED(默认模式)：业务方法需要在一个容器里运行。如果方法运行时，已经处在一个事务中，那么加入到这个事务，否则自己新建一个新的事务。

2、NOT_SUPPORTED：声明方法不需要事务。如果方法没有关联到一个事务，容器不会为他开启事务，如果方法在一个事务中被调用，该事务会被挂起，调用结束后，原先的事务会恢复执行。

3、REQUIRESNEW：不管是否存在事务，该方法总汇为自己发起一个新的事务。如果方法已经运行在一个事务中，则原有事务挂起，新的事务被创建。

4、 MANDATORY：该方法只能在一个已经存在的事务中执行，业务方法不能发起自己的事务。如果在没有事务的环境下被调用，容器抛出例外。

5、SUPPORTS：该方法在某个事务范围内被调用，则方法成为该事务的一部分。如果方法在该事务范围外被调用，该方法就在没有事务的环境下执行。

6、NEVER：该方法绝对不能在事务范围内执行。如果在就抛例外。只有该方法没有关联到任何事务，才正常执行。

7、NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中。如果没有活动事务，则按REQUIRED属性执行。它使用了一个单独的事务，这个事务拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效。

Isolation 事务的隔离级别，默认值为 Isolation.DEFAULT。

1、Isolation.DEFAULT：使用底层数据库默认的隔离级别。

2、Isolation.READ_UNCOMMITTED

3、Isolation.READ_COMMITTED

4、Isolation.REPEATABLE_READ

5、Isolation.SERIALIZABLE

timeout事务的超时时间，默认值为 -1。如果超过该时间限制但事务还没有完成，则自动回滚事务。

readOnly指定事务是否为只读事务，默认值为 false；为了忽略那些不需要事务的方法，比如读取数据，可以设置 read-only 为 true。

rollbackFor用于指定能够触发事务回滚的异常类型，可以指定多个异常类型。

noRollbackFor抛出指定的异常类型，不回滚事务，可以指定多个异常类型

END

扫码关注更多精彩

点亮在看，你最好看！