事务注解 @Transactional 失效的3种场景及解决办法

本文详细解析@Transactional注解在非public方法、类内部调用和异常捕获时的失效原因,以及Spring AOP动态代理原理在事务管理中的作用。

Transactional失效场景介绍

第一种 Transactional注解标注方法修饰符为非public时,@Transactional注解将会不起作用。例如以下代码。

定义一个错误的@Transactional标注实现,修饰一个默认访问符的方法

/**
 * @author zhoujy
 **/
@Component
public class TestServiceImpl {
    @Resource
    TestMapper testMapper;
    
    @Transactional
    void insertTestWrongModifier() {
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }

}

在同一个包内,新建调用对象,进行访问。

@Component
public class InvokcationService {
    @Resource
    private TestServiceImpl testService;
    public void invokeInsertTestWrongModifier(){
        //调用@Transactional标注的默认访问符方法
        testService.insertTestWrongModifier();
    }
}

测试用例

@RunWith(SpringRunner.class)
@SpringBootTest
public class DemoApplicationTests {
   @Resource
   InvokcationService invokcationService;

   @Test
   public void  testInvoke(){
      invokcationService.invokeInsertTestWrongModifier();
   }
}

以上的访问方式,导致事务没开启,因此在方法抛出异常时,testMapper.insert(new Test(10,20,30));操作不会进行回滚。如果TestServiceImpl#insertTestWrongModifier方法改为public的话将会正常开启事务,testMapper.insert(new Test(10,20,30));将会进行回滚。

第二种

在类内部调用调用类内部@Transactional标注的方法。这种情况下也会导致事务不开启。示例代码如下。

设置一个内部调用

/**
 * @author zhoujy
 **/
@Component
public class TestServiceImpl implements TestService {
    @Resource
    TestMapper testMapper;

    @Transactional
    public void insertTestInnerInvoke() {
        //正常public修饰符的事务方法
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }


    public void testInnerInvoke(){
        //类内部调用@Transactional标注的方法。
        insertTestInnerInvoke();
    }

}

测试用例。

@RunWith(SpringRunner.class)
@SpringBootTest
public class DemoApplicationTests {

   @Resource
   TestServiceImpl testService;

   /**
    * 测试内部调用@Transactional标注方法
    */
   @Test
   public void  testInnerInvoke(){
       //测试外部调用事务方法是否正常
      //testService.insertTestInnerInvoke();
       //测试内部调用事务方法是否正常
      testService.testInnerInvoke();
   }
}

上面就是使用的测试代码,运行测试知道,外部调用事务方法能够征程开启事务,testMapper.insert(new Test(10,20,30))操作将会被回滚;

然后运行另外一个测试用例,调用一个方法在类内部调用内部被@Transactional标注的事务方法,运行结果是事务不会正常开启,testMapper.insert(new Test(10,20,30))操作将会保存到数据库不会进行回滚。推荐:Java面试练题宝典

第三种

事务方法内部捕捉了异常,没有抛出新的异常,导致事务操作不会进行回滚。示例代码如下。

/**
 * @author zhoujy
 **/
@Component
public class TestServiceImpl implements TestService {
    @Resource
    TestMapper testMapper;

    @Transactional
    public void insertTestCatchException() {
        try {
            int re = testMapper.insert(new Test(10,20,30));
            if (re > 0) {
                //运行期间抛异常
                throw new NeedToInterceptException("need intercept");
            }
            testMapper.insert(new Test(210,20,30));
        }catch (Exception e){
            System.out.println("i catch exception");
        }
    }
    
}

测试用例代码如下。

@RunWith(SpringRunner.class)
@SpringBootTest
public class DemoApplicationTests {

   @Resource
   TestServiceImpl testService;

   @Test
   public void testCatchException(){
      testService.insertTestCatchException();
   }
}

运行测试用例发现,虽然抛出异常,但是异常被捕捉了,没有抛出到方法 外, testMapper.insert(new Test(210,20,30))操作并没有回滚。

以上三种就是@Transactional注解不起作用,@Transactional注解失效的主要原因。下面结合spring中对于@Transactional的注解实现源码分析为何导致@Transactional注解不起作用。

@Transactional注解不起作用原理分析

第一种

@Transactional注解标注方法修饰符为非public时,@Transactional注解将会不起作用。这里分析 的原因是,@Transactional是基于动态代理实现的,@Transactional注解实现原理中分析了实现方法,在bean初始化过程中,对含有@Transactional标注的bean实例创建代理对象,这里就存在一个spring扫描@Transactional注解信息的过程,不幸的是源码中体现,标注@Transactional的方法如果修饰符不是public,那么就默认方法的@Transactional信息为空,那么将不会对bean进行代理对象创建或者不会对方法进行代理调用

@Transactional注解实现原理中,介绍了如何判定一个bean是否创建代理对象,大概逻辑是。根据spring创建好一个aop切点BeanFactoryTransactionAttributeSourceAdvisor实例,遍历当前bean的class的方法对象,判断方法上面的注解信息是否包含@Transactional,如果bean任何一个方法包含@Transactional注解信息,那么就是适配这个BeanFactoryTransactionAttributeSourceAdvisor切点。则需要创建代理对象,然后代理逻辑为我们管理事务开闭逻辑。

spring源码中,在拦截bean的创建过程,寻找bean适配的切点时,运用到下面的方法,目的就是寻找方法上面的@Transactional信息,如果有,就表示切点BeanFactoryTransactionAttributeSourceAdvisor能够应用(canApply)到bean中,

AopUtils#canApply(org.springframework.aop.Pointcut, java.lang.Class<?>, boolean)

public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {
   Assert.notNull(pc, "Pointcut must not be null");
   if (!pc.getClassFilter().matches(targetClass)) {
      return false;
   }

   MethodMatcher methodMatcher = pc.getMethodMatcher();
   if (methodMatcher == MethodMatcher.TRUE) {
      // No need to iterate the methods if we're matching any method anyway...
      return true;
   }

   IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;
   if (methodMatcher instanceof IntroductionAwareMethodMatcher) {
      introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;
   }

    //遍历class的方法对象
   Set<Class<?>> classes = new LinkedHashSet<Class<?>>(ClassUtils.getAllInterfacesForClassAsSet(targetClass));
   classes.add(targetClass);
   for (Class<?> clazz : classes) {
      Method[] methods = ReflectionUtils.getAllDeclaredMethods(clazz);
      for (Method method : methods) {
         if ((introductionAwareMethodMatcher != null &&
               introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions)) ||
             //适配查询方法上的@Transactional注解信息  
             methodMatcher.matches(method, targetClass)) {
            return true;
         }
      }
   }

   return false;
}

我们可以在上面的方法打断点,一步一步调试跟踪代码,最终上面的代码还会调用如下方法来判断。在下面的方法上断点,回头看看方法调用堆栈也是不错的方式跟踪。推荐:Java面试练题宝典

AbstractFallbackTransactionAttributeSource#getTransactionAttribute

  • AbstractFallbackTransactionAttributeSource#computeTransactionAttribute

protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) {
   // Don't allow no-public methods as required.
   //非public 方法,返回@Transactional信息一律是null
   if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
      return null;
   }
   //后面省略.......
 }

不创建代理对象

所以,如果所有方法上的修饰符都是非public的时候,那么将不会创建代理对象。以一开始的测试代码为例,如果正常的修饰符的testService是下面图片中的,经过cglib创建的代理对象。

图片

如果class中的方法都是非public的那么将不是代理对象。

图片

不进行代理调用

考虑一种情况,如下面代码所示。两个方法都被@Transactional注解标注,但是一个有public修饰符一个没有,那么这种情况我们可以预见的话,一定会创建代理对象,因为至少有一个public修饰符的@Transactional注解标注方法。

创建了代理对象,insertTestWrongModifier就会开启事务吗?答案是不会。

/**
 * @author zhoujy
 **/
@Component
public class TestServiceImpl implements TestService {
    @Resource
    TestMapper testMapper;

    @Override
    @Transactional
    public void insertTest() {
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }
    
    @Transactional
    void insertTestWrongModifier() {
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }
}

原因是在动态代理对象进行代理逻辑调用时,在cglib创建的代理对象的拦截函数中CglibAopProxy.DynamicAdvisedInterceptor#intercept,有一个逻辑如下,目的是获取当前被代理对象的当前需要执行的method适配的aop逻辑。

List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);

而针对@Transactional注解查找aop逻辑过程,相似地,也是执行一次

AbstractFallbackTransactionAttributeSource#getTransactionAttribute

  • AbstractFallbackTransactionAttributeSource#computeTransactionAttribute

也就是说还需要找一个方法上的@Transactional注解信息,没有的话就不执行代理@Transactional对应的代理逻辑,直接执行方法。没有了@Transactional注解代理逻辑,就无法开启事务,这也是上一篇已经讲到的。

第二种

在类内部调用调用类内部@Transactional标注的方法。这种情况下也会导致事务不开启。

经过对第一种的详细分析,对这种情况为何不开启事务管理,原因应该也能猜到;

既然事务管理是基于动态代理对象的代理逻辑实现的,那么如果在类内部调用类内部的事务方法,这个调用事务方法的过程并不是通过代理对象来调用的,而是直接通过this对象来调用方法,绕过的代理对象,肯定就是没有代理逻辑了。

其实我们可以这样玩,内部调用也能实现开启事务,代码如下。

/**
 * @author zhoujy
 **/
@Component
public class TestServiceImpl implements TestService {
    @Resource
    TestMapper testMapper;

    @Resource
    TestServiceImpl testServiceImpl;


    @Transactional
    public void insertTestInnerInvoke() {
        int re = testMapper.insert(new Test(10,20,30));
        if (re > 0) {
            throw new NeedToInterceptException("need intercept");
        }
        testMapper.insert(new Test(210,20,30));
    }


    public void testInnerInvoke(){
        //内部调用事务方法
        testServiceImpl.insertTestInnerInvoke();
    }

}

上面就是使用了代理对象进行事务调用,所以能够开启事务管理,但是实际操作中,没人会闲的蛋疼这样子玩~

第三种

事务方法内部捕捉了异常,没有抛出新的异常,导致事务操作不会进行回滚。

这种的话,可能我们比较常见,问题就出在代理逻辑中,我们先看看源码里卖弄动态代理逻辑是如何为我们管理事务的。

TransactionAspectSupport#invokeWithinTransaction

代码如下。

protected Object invokeWithinTransaction(Method method, Class<?> targetClass, final InvocationCallback invocation)
      throws Throwable {

   // If the transaction attribute is null, the method is non-transactional.
   final TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
   final PlatformTransactionManager tm = determineTransactionManager(txAttr);
   final String joinpointIdentification = methodIdentification(method, targetClass);

   if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
      // Standard transaction demarcation with getTransaction and commit/rollback calls.
       //开启事务
      TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
      Object retVal = null;
      try {
         // This is an around advice: Invoke the next interceptor in the chain.
         // This will normally result in a target object being invoked.
          //反射调用业务方法
         retVal = invocation.proceedWithInvocation();
      }
      catch (Throwable ex) {
         // target invocation exception
          //异常时,在catch逻辑中回滚事务
         completeTransactionAfterThrowing(txInfo, ex);
         throw ex;
      }
      finally {
         cleanupTransactionInfo(txInfo);
      }
       //提交事务
      commitTransactionAfterReturning(txInfo);
      return retVal;
   }

   else {
     //....................
   }
}

所以看了上面的代码就一目了然了,事务想要回滚,必须能够在这里捕捉到异常才行,如果异常中途被捕捉掉,那么事务将不会回滚。

总结了以上几种情况。

<think>首先,用户的问题是关于Spring框架中@Transactional注解失效的原因和解决方案。根据系统指令,我需要使用中文回答,并确保回答结构清晰,帮助用户逐步解决问题。 回顾用户的问题:"请问@Transactional 注解失效的原因和解决方案"。用户引用了几个参考内容,这些内容讨论了@Transactional注解失效场景,如自调用、异常处理、方法修饰符等。 关键点从引用中提取: - 引用[1]:提到自调用导致事务失效,因为方法是通过this对象调用,而不是代理对象。解决方案是避免自调用或使用其他方式。 - 引用[2]:列出多个失效场景,包括自调用、异常被catch、非public方法、rollbackFor设置错误、propagation设置错误、数据库引擎不支持事务。 - 引用[3]:类似地,讨论传播行为、隔离级别等属性。 - 引用[4]:展示了注入调用方式。 我的回答需要覆盖这些失效原因和解决方案,并基于这些引用提供可靠的信息。 回答结构: 1. **引言**:简要介绍@Transactional注解的作用,然后过渡到常见失效原因。 2. **失效原因**:列出并解释主要失效场景,参考引用内容。 3. **解决方案**:针对每个原因提供相应的解决方案。 4. **总结**:强调最佳实践。 5. **生成相关问题**:如系统指令要求,生成相关问题。 确保回答真实可靠:基于提供的引用和Spring框架的常见知识。 现在,列出主要失效原因和解决方案: 1. **自调用(同一个类中方法调用)**: - 原因:当方法A调用同一个类中的方法B(@Transactional注解的方法),由于Spring使用代理,方法A是通过this调用,而不是代理对象,导致事务不生效。 - 解决方案:避免自调用;将方法B提取到另一个类中;使用AspectJ模式;或通过ApplicationContext获取代理对象。 2. **异常被catch处理**: - 原因:如果@Transactional方法中抛出异常,但被catch块捕获且未重新抛出,事务管理器无法检测到异常,从而不会回滚。 - 解决方案:确保异常传播到事务管理器;在catch块中重新抛出异常或抛出RuntimeException;使用rollbackFor属性指定回滚的异常类型。 3. **方法非public修饰**: - 原因:Spring事务代理默认只对public方法有效。如果方法是非public(如private、protected),代理可能不会应用事务。 - 解决方案:确保@Transactional注解的方法为public。 4. **rollbackFor属性设置错误**: - 原因:默认只对RuntimeException和Error回滚。如果方法抛出checked异常,事务不会回滚。 - 解决方案:设置rollbackFor属性为需要的异常类型,如@Transactional(rollbackFor = Exception.class)。 5. **propagation属性设置错误**: - 原因:传播行为设置不当可能导致事务不生效,如使用PROPAGATION_NOT_SUPPORTED。 - 解决方案:正确设置传播行为,确保事务正确传播。 6. **数据库引擎不支持事务**: - 原因:如MyISAM引擎在MySQL中不支持事务。 - 解决方案:使用支持事务的引擎,如InnoDB。 7. **其他原因**:如配置问题、代理模式等。 在回答中,自然地添加引用标识,例如在解释后添加[^1], [^2]等。 最后,生成相关问题: - 基于主题,如事务传播行为、隔离级别、优化等。 - 例如: 1. 如何配置Spring事务的传播行为? 2. @Transactional注解的rollbackFor属性如何工作? 3. 在分布式系统中如何处理事务? 确保使用LaTeX格式: - 行内数学表达式用$...$,但这里可能不涉及数学,所以可能不需要。 - 如果有代码块,用```...```格式。 现在,构建回答: - 开头:介绍 - 主体:分点解释原因和解决方案 - 结尾:总结和生成相关问题</think>### @Transactional 注解失效的原因及解决方案 Spring框架中的`@Transactional`注解是声明式事务管理的核心工具,用于简化数据库事务控制。然而,在实际使用中,可能会因配置或代码问题导致事务失效。以下是常见失效原因及解决方案,基于Spring事务机制的分析。 #### 一、失效原因 1. **同一个类中方法自调用** - **原因**:当一个类中的方法A调用同一个类中的方法B(被`@Transactional`注解修饰)时,方法B是通过`this`对象直接调用的,而不是通过Spring的CGLIB或JDK动态代理对象。这导致事务拦截器无法生效,事务无法被Spring管理[^1][^2]。 - **示例**: ```java @Service public class UserService { public void methodA() { methodB(); // 自调用,事务失效 } @Transactional public void methodB() { // 数据库操作 } } ``` 2. **异常被catch处理且未重新抛出** - **原因**:`@Transactional`默认只在抛出`RuntimeException`或`Error`时回滚事务。如果方法中捕获了异常(如`try-catch`块),且未重新抛出或未指定回滚异常类型,事务管理器无法感知异常,导致事务不会回滚[^2][^3]。 - 例如,捕获`Exception`后未处理: ```java @Transactional public void update() { try { // 数据库操作 } catch (Exception e) { // 未重新抛出异常 } } ``` 3. **方法非public修饰** - **原因**:Spring的事务代理机制基于AOP,默认只对`public`方法生效。如果方法被声明为`private`、`protected`或包级私有,代理无法拦截调用,事务失效[^2][^3]。 4. **rollbackFor属性设置错误** - **原因**:默认情况下,`@Transactional`仅对`RuntimeException`回滚。如果方法抛出checked异常(如`IOException`),且未通过`rollbackFor`显式指定,事务不会回滚[^2][^3]。 - 错误示例:`@Transactional`未指定`rollbackFor`,但方法抛出`SQLException`。 5. **propagation属性设置错误** - **原因**:传播行为(如`Propagation.NOT_SUPPORTED`)配置不当可能导致事务不生效。例如,若父方法已开启事务,子方法设置为`Propagation.NEVER`会抛出异常,事务中断[^2][^3]。 6. **数据库引擎不支持事务** - **原因**:某些数据库引擎(如MySQL的MyISAM)不支持事务操作。即使代码正确,事务也无法生效[^2]。 7. **配置问题** - **原因**:未启用事务管理(如缺少`@EnableTransactionManagement`)、代理模式错误(如未使用CGLIB),或Bean未被Spring容器管理。 #### 二、解决方案 针对上述原因,提供以下解决方案: 1. **避免自调用** - 将事务方法移到另一个Bean中,通过依赖注入调用[^1][^4]。 ```java @Service public class ServiceA { @Autowired private ServiceB serviceB; // 注入代理对象 public void methodA() { serviceB.methodB(); // 通过代理调用 } } @Service public class ServiceB { @Transactional public void methodB() { // 事务生效 } } ``` - 或使用`AopContext.currentProxy()`获取当前代理对象(需开启`exposeProxy=true`)。 2. **正确处理异常** - 在catch块中重新抛出异常,或设置`rollbackFor`指定回滚的异常类型[^2][^3]。 ```java @Transactional(rollbackFor = Exception.class) // 指定所有异常回滚 public void update() { try { // 数据库操作 } catch (Exception e) { throw new RuntimeException(e); // 重新抛出 } } ``` 3. **确保方法为public** - 所有`@Transactional`方法必须声明为`public`[^2][^3]。 4. **正确配置rollbackFor** - 显式定义`rollbackFor`以覆盖checked异常。 ```java @Transactional(rollbackFor = {SQLException.class, IOException.class}) ``` 5. **合理设置传播行为** - 根据业务场景选择传播行为,例如默认`Propagation.REQUIRED`(支持当前事务,不存在则创建新事务)。 ```java @Transactional(propagation = Propagation.REQUIRED) ``` 6. **检查数据库和配置** - 使用支持事务的引擎(如MySQL的InnoDB)。 - 确保配置正确:添加`@EnableTransactionManagement`,检查数据源事务管理器Bean。 7. **其他最佳实践** - 避免在Controller层使用`@Transactional`,推荐在Service层实现。 - 测试事务:使用`TransactionTemplate`或单元测试验证事务回滚。 #### 三、总结 `@Transactional`失效多由代理机制、异常处理或配置疏忽引起。通过避免自调用、正确处理异常、规范方法修饰符和属性设置,可有效解决大部分问题。建议结合Spring官方文档和日志调试事务行为[^2][^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值