大佬教程收集整理的这篇文章主要介绍了为什么catch了异常,但事务还是回滚了?,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
前几天我发了这篇文章《我来出个题:这个事务会不会回滚?》得到了很多不错的反馈,也有不少读者通过微信、群或者邮件的方式,给了我一些关于test4的回复。其中还有直接发给我测试案例,来证明我的答案是错的。今天,我们就来一起看看test4这个争议很大的问题。如果您是刚打开这篇文章,不了解我们在讨论啥,那可以先点击查看之前的这篇《我来出个题:这个事务会不会回滚?》。通过这两篇文章的解析,相信你会对Spring Data JPA下的事务执行机制有质的飞跃。
先来说说,那些写了代码验证"不会回滚"的情况,把这些错误答案的原因先说清楚,然后再细说test4会回滚的情况。
根据这两天读者给我的案例或者描述清楚的一些情况,归结了一下,大家写的验证代码之所以不会回滚,主要有以下三个原因:
归家一下出现这些疑问的原因:没审题和事务基础掌握不牢导致。关于事务基础使用的一些常见注意点,之前写过一篇文章,如果觉得这方面知识还不扎实的,建议读一读:《为什么加了@transactional注解,事务没有回滚?》
先来看看执行时候报的异常:
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,分享外面看不到的干货与思考!
以上是大佬教程为你收集整理的为什么catch了异常,但事务还是回滚了?全部内容,希望文章能够帮你解决为什么catch了异常,但事务还是回滚了?所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。