为什么在Hibernate中进行只读操作时需要事务？
以下事务是否会在数据库中放置锁定？
从数据库获取的示例代码：
Transaction tx = HibernateUtil.getCurrentSession().beginTransaction(); // why begin transaction?
//readonly operation here
tx.commit() // why tx.commit? I don't want to write anything
读取事务的操作可能看起来很奇怪，通常人们在这种情况下不会为事务标记方法。但是JDBC将仍然创建事务，只是如果没有显式设置不同选项，它将在autocommit=true模式下工作。但是有实际理由标记只读事务：
没有保证您的方法不会写入数据库。如果将方法标记为@Transactional(readonly=true)，则您将规定在此事务范围内是否“实际上”可以写入DB。如果您的架构繁琐，某些团队成员可能会选择把修改查询放在意料之外的地方，那么这个标志将指向有问题的地方。
所有数据库语句都在物理事务的上下文中执行，即使我们没有显式声明事务边界（例如 BEGIN、COMMIT、ROLLBACK）。
如果您不显式声明事务边界，则每个语句都必须在单独的事务中执行（自动提交模式）。这甚至可能导致每条语句打开和关闭一个连接，除非您的环境可以处理每个线程绑定一个连接。
将服务声明为 @Transactional 将为整个事务持续时间提供一个连接，并且所有语句将使用该单个隔离连接。这比一开始不使用显式事务要好得多。
在大型应用程序中，您可能有许多并发请求，减少数据库连接获取请求率肯定会提高整体应用程序性能。
JPA 不会对读操作强制执行事务。只有写入操作才会在您忘记启动事务上下文时引发 TransactionRequiredException。尽管如此，即使是只读事务也最好声明事务边界（在 Spring 中，@Transactional 允许您标记只读事务，这具有很大的性能优势）。
事务确实会对数据库进行锁定——好的数据库引擎以明智的方式处理并发锁定——并且在只读使用时非常有用，以确保没有其他事务添加数据，使您的视图不一致。您总是需要一个事务（尽管有时调整隔离级别是合理的，但最好不要从一开始就这样做）；如果您在事务期间从未写入DB，则提交和回滚事务都将得出相同的结果（并且非常便宜）。
现在，如果您很幸运，对DB的查询是ORM始终将它们映射到单个SQL查询，那么您可以不需要显式事务，并依赖于DB的内置自动提交行为，但ORM是相对复杂的系统，因此除非您更加努力地检查实现操作，否则不安全。编写显式事务边界要容易得多（特别是如果您可以使用AOP或某些类似于ORM驱动的技术来执行它；从Java 7开始，也可以使用try-with-resources）。