@Transactional 事务注解

  • 前言
    • 一、什么是事务?
    • 二、事务的特性 (具有ACID的特性)
    • 三、@Transactional属性详解
    • 四、注解失效问题

前言

一、什么是事务” />

四、注解失效问题

  1. @Transactional 应用在非 public 修饰的方法上
    事务拦截器在目标方法执行前后进行拦截,内部会调用方法来获取Transactional 注解的事务配置信息,调用前会检查目标方法的修饰符是否为 public,不是 public则不会获取@Transactional 的属性配置信息。

  2. @Transactional 注解属性 rollbackFor 设置错误
    rollbackFor 可以指定能够触发事务回滚的异常类型。Spring默认抛出了未检查unchecked异常(继承自 RuntimeException 的异常)或者 Error才回滚事务;其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常,但却期望 Spring 能够回滚事务,就需要指定rollbackFor属性。

  3. 同一个类中方法调用,导致@Transactional失效
    开发中避免不了会对同一个类里面的方法调用,比如有一个类Test,它的一个方法A,A再调用本类的方法B(不论方法B是用public还是private修饰),但方法A没有声明注解事务,而B方法有。则外部调用方法A之后,方法B的事务是不会起作用的。这也是经常犯错误的一个地方。

那为啥会出现这种情况?其实这还是由于使用Spring AOP代理造成的,因为只有当事务方法被当前类以外的代码调用时,才会由Spring生成的代理对象来管理。

  1. 异常被你的 catch“吃了”导致@Transactional失效
    如果你手动的catch捕获这个异常并进行处理,事务管理器会认为当前事务应该正常commit,就会导致注解失效,如果非要捕获且不失效,就必须在代码块内throw new Exception抛出异常。

  2. 数据库引擎不支持事务
    开启事务的前提就是需要数据库的支持,我们一般使用的Mysql引擎时支持事务的,所以一般不会出现这种问题。

  3. 开启多线程任务时,事务管理会受到影响
    因为线程不属于spring托管,故线程不能够默认使用spring的事务,也不能获取spring注入的bean在被spring声明式事务管理的方法内开启多线程,多线程内的方法不被事务控制。
    另外,使用多线程事务的情况下,进行回滚,比较麻烦。thread的run方法,有个特别之处,它不会抛出异常,但异常会导致线程终止运行。
    最麻烦的是,在线程中抛出的异常即使在主线程中使用try…catch也无法解释。这非常糟糕,我们必须要“感知”到异常的发生。比如某个线程在处理重要的事务,当thread异常终止,我必须要收到异常的报告,才能回滚事务。这时可以使用线程的UncaughtExceptionHandler进行异常处理,UncaughtExceptionHandler名字意味着处理未捕获的异常。更明确地说,它处理未捕获的运行异常。