前一段时间,项目代码评审,发现有TX不使用Spring的事务处理,而直接封装方法,手动进行数据的回滚,得悉原因是:抛出异常以后事务不起作用,没有回滚。这理由顿时让人很无语,不过还算个聪明的TX,知晓另辟蹊径,但是在insert的时候,手动回滚直接delete就可以了,如果是update,不晓得还会有什么更犀利的办法。
仔细评审代码细节,发现该TX压根没有按照框架原先设计在service层throws BusinessException,而是直接throws Exception。Spring配置异常回滚采用的是rollback-for=“BusinessException”。TX提出疑问:Spring不是抛出异常事务就会回滚么?带着疑问,查阅资料,分析源代码,最终找到想要的答案。这一切来源于java的检查性异常、非检查性异常的区别。
使用spring难免要用到spring的事务管理,要用事务管理又会很自然的选择声明式的事务管理,在spring的文档中说道,spring声明式事务管理默认对非检查型异常和运行时异常进行事务回滚,而对检查型异常则不进行回滚操作。
那么什么是检查型异常什么又是非检查型异常呢?
最简单的判断点有两个:
1.继承自runtimeexception或error的是非检查型异常,而继承自exception的则是检查型异常(当然,runtimeexception本身也是exception的子类)。
2.对非检查型类异常可以不用捕获,而检查型异常则必须用try语句块进行处理或者把异常交给上级方法处理总之就是必须写代码处理它。所以必须在service捕获异常,然后再次抛出,这样事务方才起效。
本文深入探讨了Spring框架中事务管理的机制,特别是针对检查性异常和非检查性异常的处理方式。通过具体案例分析,解释了为什么直接抛出检查性异常会导致事务无法回滚,并给出了正确的异常处理方法。
1093

被折叠的 条评论
为什么被折叠?



