为什么在Hibernate中需要事务才能进行只读操作？

Question

为什么在Hibernate中需要事务才能进行只读操作？

以下事务是否在数据库中设置了锁定？

从数据库获取示例代码：

Transaction tx = HibernateUtil.getCurrentSession().beginTransaction(); // why begin transaction?

//readonly operation here

tx.commit() // why tx.commit? I don't want to write anything

我可以session.close() 代替使用tx.commit()吗？

Answer 1

所有数据库语句都在物理事务的上下文中执行，即使我们没有显式声明事务边界（BEGIN / COMMIT / ROLLBACK）也是如此。如果您未明确声明事务边界，则每个语句将必须在单独的事务（autocommit模式）中执行。除非您的环境无法处理每线程连接绑定，否则这甚至可能导致每个语句打开和关闭一个连接。将服务声明为as @Transactional将在整个事务期间为您提供一个连接，并且所有语句将使用该单个隔离连接。这比首先不使用显式事务更好。在大型应用程序上，您可能有许多并发请求，降低数据库连接获取请求率肯定会提高整体应用程序性能。JPA不会对读取操作强制执行事务。只有在您忘记启动事务上下文的情况下，写操作才会引发事务必需的异常。但是，即使对于只读事务，也最好声明事务边界（在Spring中@Transactional，您可以标记只读事务，这具有很大的性能优势）。

Answer 2

事务确实在数据库上加了锁-好的数据库引擎以一种明智的方式处理并发锁-并且对于只读使用很有用，以确保没有其他事务添加任何会使您的视图不一致的数据。您总是想要一个事务（尽管有时调整隔离级别是合理的，但是最好不要这样做）。如果您在事务期间从不向数据库写入数据，则提交和回滚事务的结果是相同的（而且非常便宜）。现在，如果您很幸运，并且对数据库的查询使得ORM始终将它们映射到单个SQL查询，则可以依靠数据库的内置自动提交行为而无需显式事务就可以逃脱，但是ORM是相对复杂的系统因此，依靠这种行为是绝对不安全的，除非您去做更多的工作来检查实现的实际作用。在其中编写明确的事务边界要容易得多（特别是如果您可以使用AOP或一些类似的ORM驱动的技术来做到这一点；我想从Java 7开始，也可以使用try-with-resources）。