对Spring JpaTransactionManager的误解

柔光的暖阳◎ 2022-02-13 23:21 327阅读 0赞

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

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

逻辑层代码实现如下：

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

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

public class MyJpaTransactionManager extendsJpaTransactionManager\{  
 protected transient Log logger =LogFactory.getLog(getClass());  
 @Override  
 protected void doCommit(DefaultTransactionStatusstatus) \{  
  if(status.isReadOnly())\{  
   logger.info("Thisa read only transaction.");  
  \}  
  else\{  
   super.doCommit(status);  
  \}  
 \}  
\}

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

[https://jira.springsource.org/browse/SPR-8959][https_jira.springsource.org_browse_SPR-8959]

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

对框架的验证及其重要，发现问题时应该以SR的形式提交社区探讨，确认解决方案，并做详细的POC验证测试。

[https_jira.springsource.org_browse_SPR-8959]: https://jira.springsource.org/browse/SPR-8959