@Transactional注解的失效場景

1、@Transactional 應用在非 public 修飾的方法上

　　如果Transactional注解應用在非public 修飾的方法上，Transactional將會失效。

 

　　之所以會失效是因為在Spring AOP 代理時，如上圖所示 TransactionInterceptor （事務攔截器）在目標方法執行前后進行攔截，DynamicAdvisedInterceptor（CglibAopProxy 的內部類）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法會間接調用 AbstractFallbackTransactionAttributeSource的 computeTransactionAttribute 方法，獲取Transactional 注解的事務配置信息。

protected TransactionAttribute computeTransactionAttribute(Method method,
    Class<?> targetClass) {
        // Don't allow no-public methods as required.
        if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
        return null;
}

　　此方法會檢查目標方法的修飾符是否為 public，不是 public則不會獲取@Transactional 的屬性配置信息。

注意：protected、private 修飾的方法上使用 @Transactional 注解，雖然事務無效，但不會有任何報錯，這是我們很容犯錯的一點。

2、@Transactional 注解屬性 propagation 設置錯誤

　　這種失效是由於配置錯誤，若是錯誤的配置以下三種 propagation，事務將不會發生回滾。

TransactionDefinition.PROPAGATION_SUPPORTS：如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續運行。 TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事務方式運行，如果當前存在事務，則把當前事務掛起。 TransactionDefinition.PROPAGATION_NEVER：以非事務方式運行，如果當前存在事務，則拋出異常。

3、@Transactional 注解屬性 rollbackFor 設置錯誤

　　ollbackFor 可以指定能夠觸發事務回滾的異常類型。Spring默認拋出了未檢查unchecked異常（繼承自 RuntimeException 的異常）或者 Error才回滾事務；其他異常不會觸發回滾事務。如果在事務中拋出其他類型的異常，但卻期望 Spring 能夠回滾事務，就需要指定 rollbackFor屬性。

 

 

// 希望自定義的異常可以進行回滾 @Transactional(propagation= Propagation.REQUIRED,rollbackFor= MyException.class

　　若在目標方法中拋出的異常是 rollbackFor 指定的異常的子類，事務同樣會回滾。Spring源碼如下：

private int getDepth(Class<?> exceptionClass, int depth) {
        if (exceptionClass.getName().contains(this.exceptionName)) {
            // Found it!
            return depth;
}
        // If we've gone as far as we can go and haven't found it...
        if (exceptionClass == Throwable.class) {
            return -1;
}
return getDepth(exceptionClass.getSuperclass(), depth + 1);
}

4、同一個類中方法調用，導致@Transactional失效

　　開發中避免不了會對同一個類里面的方法調用，比如有一個類Test，它的一個方法A，A再調用本類的方法B（不論方法B是用public還是private修飾），但方法A沒有聲明注解事務，而B方法有。則外部調用方法A之后，方法B的事務是不會起作用的。這也是經常犯錯誤的一個地方。

　　那為啥會出現這種情況？其實這還是由於使用Spring AOP代理造成的，因為只有當事務方法被當前類以外的代碼調用時，才會由Spring生成的代理對象來管理。

//@Transactional
    @GetMapping("/test")
    private Integer A() throws Exception {
        CityInfoDict cityInfoDict = new CityInfoDict();
        cityInfoDict.setCityName("2");
        /**
         * B 插入字段為 3的數據
         */
        this.insertB();
        /**
         * A 插入字段為 2的數據
         */
        int insert = cityInfoDictMapper.insert(cityInfoDict);

        return insert;
    }

    @Transactional()
    public Integer insertB() throws Exception {
        CityInfoDict cityInfoDict = new CityInfoDict();
        cityInfoDict.setCityName("3");
        cityInfoDict.setParentCityId(3);

        return cityInfoDictMapper.insert(cityInfoDict);
    }

5、異常被你的 catch“吃了”導致@Transactional失效

　　這種情況是最常見的一種@Transactional注解失效場景，

    @Transactional
    private Integer A() throws Exception {
        int insert = 0;
        try {
            CityInfoDict cityInfoDict = new CityInfoDict();
            cityInfoDict.setCityName("2");
            cityInfoDict.setParentCityId(2);
            /**
             * A 插入字段為 2的數據
             */
            insert = cityInfoDictMapper.insert(cityInfoDict);
            /**
             * B 插入字段為 3的數據
             */
            b.insertB();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

　　如果B方法內部拋了異常，而A方法此時try catch了B方法的異常，那這個事務還能正常回滾嗎？答案：不能！

　　會拋出異常：org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

因為當ServiceB中拋出了一個異常以后，ServiceB標識當前事務需要rollback。但是ServiceA中由於你手動的捕獲這個異常並進行處理，ServiceA認為當前事務應該正常commit。此時就出現了前后不一致，也就是因為這樣，拋出了前面的UnexpectedRollbackException異常。

　　spring的事務是在調用業務方法之前開始的，業務方法執行完畢之后才執行commit or rollback，事務是否執行取決於是否拋出runtime異常。如果拋出runtime exception 並在你的業務方法中沒有catch到的話，事務會回滾。

在業務方法中一般不需要catch異常，如果非要catch一定要拋出throw new RuntimeException()，或者注解中指定拋異常類型@Transactional(rollbackFor=Exception.class)，否則會導致事務失效，數據commit造成數據不一致，所以有些時候try catch反倒會畫蛇添足。

6、數據庫引擎不支持事務

　　這種情況出現的概率並不高，事務能否生效數據庫引擎是否支持事務是關鍵。常用的MySQL數據庫默認使用支持事務的innodb引擎。一旦數據庫引擎切換成不支持事務的myisam，那事務就從根本上失效了。

總結

@Transactional 注解的看似簡單易用，但如果對它的用法一知半解，還是會踩到很多坑的。