共计 3093 个字符,预计需要花费 8 分钟才能阅读完成。
导致 @Transactional 生效的常见场景有以下 5 个:
- 非 public 润饰的办法;
- timeout 超时工夫设置过小;
- 代码中应用 try/catch 解决异样;
- 调用类外部的 @Transactional 办法;
- 数据库不反对事务。
很多人只晓得答案但不晓得起因,这就像只谈恋爱不结婚一样,是不能让人承受的,所以本篇咱们就来讨论一下,导致事务生效的背地起因到底是啥?
在以上 5 种场景中,第 2 种(timeout 超时工夫设置过小)和第 5 种(数据库不反对事务)很好了解,咱们这里就不赘述了,本文咱们重点来探讨其余 3 种状况。
1. 非 public 润饰的办法
非 public 润饰的办法上,即便加了 @Transactional 事务仍然不会失效,起因是 因为 @Transactional 应用的是 Spring AOP 实现的,而 Spring AOP 是通过动静代理实现的,而 @Transactional 在生成代理时会判断,如果办法为非 public 润饰的办法,则不生成代理对象,这样也就没方法主动执行事务了,它的局部实现源码如下:
protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) {
// Don't allow no-public methods as required.
// 非 public 办法,设置为 null
if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {return null;}
// 前面代码省略....
}
2.try/catch 导致事务生效
@Transactional 执行流程是:@Transactional 会在办法执行前,会主动开启事务;在办法胜利执行完,会主动提交事务;如果办法在执行期间,呈现了异样,那么它会主动回滚事务。
然而 如果在办法中自行添加了 try/catch 之后,事务就不会主动回滚了 ,这是怎么回事呢?
造成这个问题的次要起因和 @Transactional 注解的实现无关,它的局部实现源码如下:
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 {// .....}
}
从上述实现源码咱们能够看出:当执行的办法中呈现了异样,@Transactional 能力感知到,而后再执行事务回滚,而当开发者自行添加了 try/catch 之后,@Transactional 就感知不到异样了,从而就不会触发事务的主动回滚了,这就是为什么当 @Transactional 遇到 try/catch 之后就不会主动回滚(事务)的起因。
3. 调用类内用的 @Transactional 办法
当调用类外部的 @Transactional 润饰的办法时,事务也不会失效,如下代码所示:
@RequestMapping("/save")
public int saveMappping(UserInfo userInfo) {return save(userInfo);
}
@Transactional
public int save(UserInfo userInfo) {
// 非空效验
if (userInfo == null ||
!StringUtils.hasLength(userInfo.getUsername()) ||
!StringUtils.hasLength(userInfo.getPassword()))
return 0;
int result = userService.save(userInfo);
int num = 10 / 0; // 此处设置一个异样
return result;
}
上述代码在增加用户之后即便遇到了异样,程序也没有执行回滚,这是 因为 @Transactional 是基于 Spring AOP 实现的,而 Spring AOP 又是基于动静代理实现的,而当调用类外部的办法时,不是通过代理对象实现的,而是通过 this 对象实现的,这样就绕过了代理对象,从而事务就生效了。
总结
非 public 润饰的办法在 @Transactional 实现时做了判断,如果是非 public 则不会生成代理对象,所以事务就生效了;而调用类外部的 @Transactional 润饰的办法时,也是因为没有胜利调用代理对象,是通过 this 来调用办法的,所以事务也生效了;@Transactional 在遇到开发者自定义的 try/catch 也会生效,这是因为 @Transactional 只有感知到了异样才会主动回滚(事务),但如果用户自定义了 try/catch,那么 @Transactional 就感知不到异样,所以也就不会主动回滚事务了。
参考 & 鸣谢
blog.csdn.net/qq_20597727/article/details/84900994
是非审之于己,毁誉听之于人,得失安之于数。
公众号:Java 面试真题解析
面试合集:https://gitee.com/mydb/interview