同类方法调用@Transaction注解的方法，事务失效（AOP原理）

ゞ浴缸里的玫瑰 2021-06-10 20:39 829阅读 0赞

##### 背景 #####

说来话巧，这次项目开发用了Oracle里面的一种事务级临时表，on commit delete rows，意味着这张临时表会在每次事务提交的时候删除数据。

##### 涉及知识点 #####

Spring事务传播机制、AOP

##### 实现方案： #####

需要对临时表的一系列操作在一个事务中执行，事务传播机制采用默认值PROPAGATION\_REQUIRED，这样只要外层有事务，事务内嵌套的事务会加入到当前事务中执行，可以实现在同一事务的需求

##### 问题出现 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center]  
插入方法用得是batchSave  
![在这里插入图片描述][2020081918491750.png_pic_center]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 1]

##### 我是如何发现问题的 #####

![在这里插入图片描述][20200819185548144.png_pic_center]  
按理说上面的batchSave方法应该是嵌套的事务，事务传播机制为PROPAGATION\_REQUIRED，不应该是Creating new transaction新建一个事务啊，难道外层的事务没生效？突然恍然大悟

#### 知识点分析 ####

基于注解的事务的实现原理是面向切面编程，通过cglib创建代理proxy，当我们访问带 @Transactional方法，如果通过spring容器获取bean，实际访问的是代理对象，代理对象已经在带 @Transactional方法前后增加了事务相关的逻辑。而当调用带 @Transactional方法的调用方是同类方法时，调用的是this对象的方法，没有通过spring容器获取bean，就无法访问到代理对象，事务也就没有生效。

#### 解决方案 ####

1、将@transactionl的方法的调用方移到其他类中  
2、通过spring注入该类的代理对象

————————————————————————————————————————————

#### 拓展：事务即便生效也不一定能回滚 ####

通过 AOP 实现事务处理可以理解为，使用 try…catch…来包裹标记了 @Transactional 注  
解的方法，当方法出现了异常并且满足一定条件的时候，在 catch 里面我们可以设置事务  
回滚，没有异常则直接提交事务。  
这里的“一定条件”，主要包括两点。

*  第一，只有异常传播出了标记了 @Transactional 注解的方法，事务才能回滚 在 Spring  
    的 TransactionAspectSupport 里有个 invokeWithinTransaction 方法，里面就是处理事  
    务的逻辑。可以看到，只有捕获到异常才能进行后续事务处理：

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
    				completeTransactionAfterThrowing(txInfo, ex);
    				throw ex;
    			}
    			finally { 
    				cleanupTransactionInfo(txInfo);
    			}

*  第二，默认情况下，出现 RuntimeException（非受检异常）或 Error 的时候，Spring  
    才会回滚事务。  
    打开 Spring 的 DefaultTransactionAttribute 类能看到如下代码块，可以发现相关证据，  
    通过注释也能看到 Spring 这么做的原因，大概的意思是受检异常一般是业务异常，或者说  
    是类似另一种方法的返回值，出现这样的异常可能业务还能完成，所以不会主动回滚；而  
    Error 或 RuntimeException 代表了非预期的结果，应该回滚：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 2]  
    接下来，我和你分享 2 个反例。  
    重新实现一下 UserService 中的注册用户操作：  
    在 createUserWrong1 方法中会抛出一个 RuntimeException，但由于方法内 catch 了  
    所有异常，异常无法从方法传播出去，事务自然无法回滚。  
    在 createUserWrong2 方法中，注册用户的同时会有一次 otherTask 文件读取操作，  
    如果文件读取失败，我们希望用户注册的数据库操作回滚。虽然这里没有捕获异常，但  
    因为 otherTask 方法抛出的是受检异常，createUserWrong2 传播出去的也是受检异  
    常，事务同样不会回滚  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 3]

#### 修复方式 ####

现在，我们来看下修复方式，以及如何通过日志来验证是否修复成功。针对这 2 种情况，  
对应的修复方法如下。  
第一，如果你希望自己捕获异常进行处理的话，也没关系，可以手动设置让当前事务处于回  
滚状态：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 4]  
第二，在注解中声明，期望遇到所有的 Exception 都回滚事务（来突破默认不回滚受检异  
常的限制）：  
![在这里插入图片描述][20200831174929649.png_pic_center]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center]: /images/20210518/5cab89633a4e466eb4584daf0f381f09.png
[2020081918491750.png_pic_center]: /images/20210518/26d331b0ef954ea6be37eb6849bfb0cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210518/b15badeb588f4bab885575c9d367afcc.png
[20200819185548144.png_pic_center]: /images/20210518/4a9daba64b0e4d8e88aea934aa8264cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20210518/081a4bbb3eec4092ac5730c775a9c886.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20210518/c247506042f5476082b010d6eec28d26.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20210518/319ba95324f8494096751d9999db96fc.png
[20200831174929649.png_pic_center]: /images/20210518/082541e078b540969d15dae3df1dcb21.png