为什么我需要Hibernate中的Transaction来进行只读操作？ [英] Why do I need Transaction in Hibernate for read only operation?

问题描述

为什么我需要Hibernate中的Transaction来进行只读操作？

以下事务是否对db进行锁定？

Why do I need Transaction in Hibernate for read only operation?
Does the following transaction put a lock on db?

从db获取的示例代码：

Example code to fetch from db:

Transcation tx = HibernateUtil.getCurrentSession().beginTranscation(); //why begin transcation?
//readonly operation here

tx.commit() // why tx.commit? i dont want to write anything

我可以使用 session.close（）而不是 tx.commit（） ??

推荐答案

您可能有理由将交易标记为只读。

You might actually have reasons to mark transactions as read-only.

1. 确实很奇怪，并且经常人们在这种情况下不标记交易的方法。但是JDBC将创建事务，只是它将在 autocommit = true 中工作，如果不明确设置不同的选项。


2. 但是不能保证你的方法不会写入数据库。如果你将方法标记为 @Transactional（readonly = true），Spring会将JDBC事务设置为只读模式，因此你将决定是否可以写入此事务范围内的DB。如果你的架构相当麻烦，有些团队成员可能不会遵循合理的路径，这个标志会指向有问题的地方。


3. 同样只读事务可以由DB优化，但这个当然是DB特定的。例如。 MySQL只在InnoDB中从5.6.4版本添加了对此的支持。


4. 如果你不直接使用JDBC，而是一个ORM，这可能是有问题的。例如Hibernate社区说，在事务外工作可能会导致不可预测的行为。这是因为Hibernate将打开事务，但它不会自己关闭它，因此连接将返回到连接池，事务未提交。那么会发生什么呢？ JDBC保持沉默，因此这是实现特定的（MySQL回滚事务，Oracle beair提交它）。这也可以在连接池级别上配置（例如C3P0给你这样的选项，默认回滚）。


5. 另一件事，当谈到Hibernate时，Spring将FlushMode设置为MANUAL


6. 您可能想要重写或显式设置事务隔离级别。这会影响读取交易，因为您确实或不想读取未提交的更改，暴露于幻影读取等。

1. Transactions for reading might look indeed strange and often people don't mark methods for transactions in this case. But JDBC will create transaction anyway, it's just it will be working in autocommit=true if different option wasn't set explicitly.
2. But there is no guarantee that your method doesn't write into the database. If you mark method as @Transactional(readonly=true), Spring will set the JDBC transaction into a read-only mode, thus you'll dictate whether it's actually possible to write into DB in scope of this transaction. If you architecture is pretty cumbersome and some team members might not follow reasonable path, this flag would point you to the problematic place.
3. Also read-only transactions can be optimized by DBs, but this of course is DB specific. E.g. MySQL added support for this only in InnoDB starting from 5.6.4 version.
4. If you're not using JDBC directly, but rather an ORM, that might be problematic. For instance Hibernate community says that working outside of transaction might cause unpredictable behavior. This is because Hibernate will open transaction, but it won't close it on its own, thus connection will be returned to the Connection Pool with transaction being not committed. What happens then? JDBC keeps silence, thus this is implementation specific (MySQL rolls back transaction, Oracle afair commits it). This also can be configured on Connection Pool level (e.g. C3P0 gives you such an option, rollback by default).
5. Another thing when it comes to Hibernate, Spring sets the FlushMode to MANUAL in case of read-only transactions, which leads to other optimizations like no need for dirty checks.
6. You may want to override or set explicitly the transaction isolation level. This impacts read-transactions as well since you do or don't want to read uncommitted changes, be exposed to phantom reads, etc.

总结 - 你可以两种方式，但你需要了解后果。

To sum up - you can go both ways, but you need to understand consequences.

这篇关于为什么我需要Hibernate中的Transaction来进行只读操作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！