对Spring JpaTransactionManager的误解

在以前项目中验证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

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

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