Spring事务中的那些坑

     项目已进展了很长时间,突然发现曾经配置过的事务居然不起作用.经项目同事一起努力,从配置到代码逐一进行排查,终于把这些坑给填上了.

1.Spring配置问题

    为了省事,没有采用注解的方式进行事务控制,即项目中的方法都不加@Transaction,而是配置了自动扫描相关包及方法的方式.

    配置如下:

        <aop:pointcut id="tms-allSysDaoMethod"
                      expression="execution(* com.######.#####.dao.*.*(..))" />
        <aop:pointcut id="tms-allSysServiceMethod"
                      expression="execution(* com.######.#####.service.*.*(..))"/>

其中: #为了项目保密,省略部分名称.

从配置信息上看,并没有什么问题,然而,关键的地方在于配置的层级跟项目代码层级不匹配.Spring中的Aop事务配置,要求配置的路径映射到具体的方法,即:service后的第一个*映射的应该是类名,第二个*对应的应该是具体的方法,(..)代表了方法的参数.

项目中,在service后依然是包名,即模块名,如:service.user,之后才是具体的类.这使得Spring根本无法扫描到要事务处理的方法.只需多加一层.*进行对应即解决问题.

2.业务代码问题

    配置文件问题解决后,依然发现有些模块事务仍然不起作用.这次的罪魁祸首是  try....catch.....

    try...catch...的作用不用多解释了,但是如果你不小心把大段的代码放置到try....catch...内部,问题可能就来了.这里的关键是,操作数据库的方法,如Mapper的方法的操作放在了try...catch...内部,你在try...catch...之前 或之后又有别的数据库的操作,那么这个时候,你就打破了事务的控制.

我们最终采用的方法时,把try....catch....放在控制器,service方法将事务往上抛.当然也可以对小范围的代码实行try....catch.....,但一定不要包含到数据库操作

总结:

1.错误认识:以为Spring可以扫描到具体的包,自动控制该包以下所有层级的类和方法事务.

2.业务代码中,try...catch...使用时,为认真检查包含的范围.