关于java:为什么catch了异常但事务还是回滚了

前几天我发了这篇文章《我来出个题：这个事务会不会回滚？》失去了很多不错的反馈，也有不少读者通过微信、群或者邮件的形式，给了我一些对于 test4 的回复。其中还有间接发给我测试案例，来证实我的答案是错的。明天，咱们就来一起看看 test4 这个争议很大的问题。如果您是刚关上这篇文章，不理解咱们在探讨啥，那能够先点击查看之前的这篇《我来出个题：这个事务会不会回滚？》。通过这两篇文章的解析，置信你会对 Spring Data JPA 下的事务执行机制有质的飞跃。

为什么没回滚

先来说说，那些写了代码验证 “ 不会回滚 ” 的状况，把这些谬误答案的起因先说分明，而后再细说 test4 会回滚的状况。

依据这两天读者给我的案例或者形容分明的一些状况，归纳了一下，大家写的验证代码之所以 不会回滚，次要有以下三个起因：

1. 没有依照我题目结尾说的，采纳 InnoDB 存储引擎，用了 MyISAM，不反对事务，天然不会复现。
2. 没用依照我题目结尾说的，采纳 JPA 和 JSR 303 校验注解，比方：用了 MyBaits，所以天然也不会复现。
3. 定义事务的函数不是 public 类型，这个根底用法就不对了，事务自身就没失效

归家一下呈现这些疑难的起因：没审题 和事务根底 把握不牢导致。对于事务根底应用的一些常见留神点，之前写过一篇文章，如果感觉这方面常识还不扎实的，倡议读一读：《为什么加了 @Transactional 注解，事务没有回滚？》

为什么写了 catch，还会回滚

先来看看执行时候报的异样：

javax.validation.ConstraintViolationException: Validation failed for classes [com.didispace.chapter310.User] during persist time for groups [javax.validation.groups.Default,]
List of constraint violations:[ConstraintViolationImpl{interpolatedMessage='个数必须在 0 和 5 之间', propertyPath=name, rootBeanClass=class com.didispace.chapter310.User, messageTemplate='{javax.validation.constraints.Size.message}'}
]
    at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:140) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:80) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:209) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:83) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:178) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$300(JdbcResourceLocalTransactionCoordinatorImpl.java:39) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]
    at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98) ~[hibernate-core-5.3.7.Final.jar:5.3.7.Final]

这个异样是这个回滚的要害。这个异样 javax.validation.ConstraintViolationException 是哪里的呢？还记得以前说的 JSR 303 不？对的，是 Bean Validation 中的异样。

有的读者说这个不是 RuntimeException，所以不会回滚。很显然，这类判断的都没有理论尝试一下，只有点开源码能够马上发现，这个异样就是属于RunTimeException 的。

实际上，之所以会回滚，与这里应用 Spring Data JPA 以及 Hibernate Validator 有间接关系。从 JPA 2.0 开始，就默认反对了这些 Bean Validation 的实现，它提供了实体生命周期中 pre-persist, pre-update,pre-remove 三个事件产生时来执行校验的性能。而在校验的时候，当校验失败，抛出 javax.validation.ConstraintViolationException 时，以后事务就会被标记为rollback。

源码解析

要想理解，这其中到底产生了什么，跟踪源码是最好的形式。那么源码从哪里开始看呢？从异样日志中找线索吧。

从异样栈中找到最近的一个谬误，点开看看。

谬误行数在 532 行tx.commit()，习惯性的加上断点，这样下一次进来的时候能够看看当前情况下的各种参数状况。

同时看到上面还有个 catch，既然 532 行出错了，那这里必定会进，所以也加个端点，到时候能够进去看看。

执行程序，调用一下 test4，执行到 532 行，而后进入下一步，看看会到哪里？

这个时候，会进入到org.hibernate.engine.transaction.internal.TransactionImpl，具体位置如下：

还是习惯性的，在上面两行重要地位加上断点，以便下次能够疾速到这里。

持续按上看的步骤尝试上来，能够来到下图的地位：

能够看到校验异样是从 271 行进去的，联合 278 行和 280 行，是不是分明这里回滚的起因了呢？

实际出真知，当你感觉困惑的时候，不如入手写一写，调一调，很多答案就能天然浮现！

如果对于 test4 会回滚还不够了解，或者你还有其余事务执行不如预期的读者，那就跟着我的思路，一步步尝试一下，能够察看的更深刻一些，你对这部分逻辑的了解就更全面了。咱们正在组建高质量的 Spring 技术交换群，欢送各种酷爱技术的开发者退出参加探讨。这里的每个人都有本人的闪光点，互相学习，舍短取长，长期保持，愿大家都会成为本人畛域里的佼佼者！

欢送关注我的公众号：程序猿 DD，分享其余中央看不到的常识与思考