首页 > 编程语言 > 详细

spring @Transactional的自调用失效问题与事务的典型错误用法剖析

时间:2019-06-16 12:45:11      阅读:267      评论:0      收藏:0      [点我收藏+]

@Transactional的自调用失效问题  

  有时候配置了注解@Transactional,但是它会失效,这里要注意一些细节问题,以避免落入陷阱。
  注解@Transaction的底层实现是Spring AOP技术,而Spring AOP技术使用的是动态代理。这就意味着对于静态(static)方法和非public方法,注解@Transactional是失效的。还有一个更为隐秘的,而且在使用过程中极其容易犯错误的——自调用。
  所谓自调用,就是一个类的一个方法去调用自身另外一个方法的过程。

  出现这个的问题根本原因在于AOP的实现原理。由于@Transactional的实现原理是AOP,而AOP的实现原理是动态代理,而自己调用自己的过程,并不存在代理对象的调用,这样就不会产生AOP去为我们设置@Transactional配置的参数,这样就出现了自调用注解失效的问题。
  为了克服这个问题,一方面可以使用两个服务类,Spring IoC容器中为你生成了RoleService的代理对象,这样就可以使用AOP,且不会出现自调用的问题。另外一方面,你也可以直接从容器中获取Service的代理对象,从IoC容器中获取RoleService代理对象。但是有一个弊端,就是从容器获取代理对象的方法有侵入之嫌,你的类需要依赖于Spring IoC容器

 

典型错误用法的剖析

   数据事务是企业应用关注的核心内容,也是开发者最容易犯错的问题,因此笔者在这里讲解一些使用不良习惯,注意它们可以避免一些错误和性能的丢失。

错误使用Service

  互联网往往采用模型—视图—控制器(Model View Con-troller,MVC)来搭建开发环境,因此在Controller中使用Service是十分常见的。
  在Controller每调用一次带事务的service都会创建数据库事务。如果多次调用,则不在同一个事务中,这会造成不同时提交和回滚不一致的问题。每一个Java EE开发者都要注意这类问题,以避免一些不必要的错误。

过长时间占用事务

  在企业的生产系统中,数据库事务资源是最宝贵的资源之一,使用了数据库事务之后,要及时释放数据库事务。换言之,我们应该尽可能地使用数据库事务资源去完成所需工作,但是在一些工作中需要使用到文件、对外连接等操作,而这些操作往往会占用较长时间,针对这些,如果开发者不注意细节,就很容易出现系统宕机的问题。
  一些系统之间的通信及一些可能需要花费较长时间的操作,都要注意这个问题,放在controller层等事务外进行处理,以避免长时间占用数据库事务,导致系统性能的低下。

错误捕捉异常

  带事务的service中,出现异常想要回滚时应抛出异常,而不是捕获

spring @Transactional的自调用失效问题与事务的典型错误用法剖析

原文:https://www.cnblogs.com/ooo0/p/11030130.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!