为什么我需要在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

我可以使用会话吗。close（）而不是tx.commit（）？

Answer 1

事务确实在数据库上设置了锁——好的数据库引擎以合理的方式处理并发锁——并且对于只读使用非常有用，可以确保没有其他事务添加会导致视图不一致的数据。您总是想要一个事务（尽管有时调整隔离级别是合理的，但最好不要从一开始就这样做）；如果在事务期间从未向数据库写入数据，那么提交和回滚事务都是一样的（而且非常便宜）。

现在，如果你很幸运，并且你对数据库的查询是这样的，ORM总是将它们映射到单个SQL查询，那么你可以不用显式事务，依赖于数据库的内置自动提交行为，但是ORM是相对复杂的系统，因此依赖这种行为根本不安全，除非你花更多的时间检查实现的实际功能。在中编写显式事务边界要容易得多（尤其是如果您可以使用AOP或类似的ORM驱动技术；从Java 7开始，我想也可以使用try with resources）。

Answer 2

所有数据库语句都在物理事务的上下文中执行，即使我们没有明确声明事务边界（例如，BEGIN、COMMIT、ROLLBACK）。

如果没有明确声明事务边界，则每个语句都必须在单独的事务中执行（autocommit模式）。这甚至可能导致每个语句打开和关闭一个连接，除非您的环境可以处理每个线程的连接绑定。

将服务声明为Transactional将在整个事务持续时间内为您提供一个连接，并且所有语句都将使用该单个隔离连接。这比一开始不使用显式事务要好得多。

在大型应用程序上，您可能会有许多并发请求，降低数据库连接获取请求率肯定会提高您的整体应用程序性能。

JPA不会对读取操作强制执行事务。只有写入操作最终会抛出Transaction必需异常，以防您忘记启动事务上下文。尽管如此，即使对于只读事务，声明事务边界总是更好的（在Spring@Transactional中，您可以标记只读事务，这具有很大的性能优势）。

Answer 3

用于读取的事务可能看起来确实很奇怪，在这种情况下，人们通常不会为事务标记方法。但JDBC无论如何都会创建事务，只是如果没有显式设置不同的选项，它将在autocommit=true下工作。但将交易标记为只读有一些实际原因：

1. 只读标志可以让DBMS优化此类事务或并行运行的事务。
2. 拥有一个跨越多个SELECT语句的事务可以保证从可重复读取或快照开始的级别的正确隔离（例如，请参阅PostgreSQL的可重复读取）。否则，如果另一个事务并行提交，2个SELECT语句可能会看到不一致的图片。使用已提交读取时，这无关紧要。

1. 如果不明确开始/完成事务，ORM可能会导致不可预测的结果。E、 g.Hibernate将在第一条语句之前打开事务，但它不会完成它。因此，连接将与未完成的事务一起返回到连接池。然后会发生什么？JDBC保持沉默，因此这是特定于实现的：MySQL、PostgreSQL驱动程序回滚此类事务，Oracle提交。请注意，这也可以在连接池级别进行配置，例如C3P0提供了这样一个选项，默认情况下为回滚

不能保证您的方法不会写入数据库。如果您将方法标记为@Transactional（readonly=true），您将决定是否可以在此事务范围内写入数据库。如果您的架构很麻烦，并且一些团队成员可能会选择将修改查询放在不期望的地方，则此标志会将您指向有问题的地方。