对Spring JpaTransactionManager的误解

在以前项目中验证Hibernate实现JPA规范的时候发现虽然在AOP配置成只读的read only的模式,但对数据库的更新操作依旧能够执行提交,如配置文件定义为:

<tx:method name="get*" read-only="true"/>

逻辑层代码实现如下:

public User getUser(User o) {
return this.entityManager.merge(o);
}

以前将问题定位为JpaTransactionManager没有对readonly进行判断,而如果换作HibernateTransactionManager则会将事务设置为MANUAL,如果不显示的提交不会修改数据库。因此误认为是JpaTransactionManager的一个BUG,因重新集成实现了一个子类:

public class MyJpaTransactionManager extends JpaTransactionManager{
protected transient Log logger = LogFactory.getLog(getClass());
@Override
protected void doCommit(DefaultTransactionStatus status) {
if(status.isReadOnly()){
logger.info("This a read only transaction.");
}
else{
super.doCommit(status);
}
}
}

后来无意浏览类似问题的解决方法时,发现国外有人也提出过类似的问题,而且得到了Juergen Hoeller本人的答复,原地址:

https://jira.springsource.org/browse/SPR-8959

奇怪的是Juergen Hoeller 并不当作一个BUG,事务read only本身仅仅是告诉业务应用有一个对数据库只读访问的暗示,这里存在可优化的地方,但若该事务出现了更新数据的操作,并不会阻止这个事务的提交。因此,重新翻出以前的代码逐行调试,寻找其中的道理。终于明白,原来对于一个事务(无论是否定义为只读)只有两种可能,要么提交,要么回滚。不管这个事务有没有提交,这个事务都会存在于应用之中。因此,若按照之前的误解,实现了上述错误的子类,那么很有可能在大并发请求数中存在大量未释放的连接,从而导致很多未知的性能瓶颈。

对框架的验证及其重要,发现问题时应该以SR的形式提交社区探讨,确认解决方案,并做详细的POC验证测试。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值