java 什么时候在 Spring 和 Hibernate 中使用事务？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5993915/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When to use transactions in Spring with Hibernate?
提问by Rihards
Upgrading my project I'm thinking here about transactions.
Well, the thing is I'm not quite sure when should I use the transactionsfor my Hibernate queries in Spring.
Not that I completely don't understand what transactions are, I guess I do, but
Do I need to use transactions for a get*type queries just setting the read-onlyattribute?
升级我的项目我在这里考虑交易。
好吧，问题是我不太确定什么时候应该在 Spring 中为我的 Hibernate 查询使用事务。
并不是说我完全不明白什么是事务，我想我明白，但是
我是否需要将事务用于get*类型查询，只是设置read-only属性？
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<!-- all methods starting with 'get' are read-only -->
<tx:method name="get*" read-only="true" />
<!-- other methods use the default transaction settings -->
<tx:method name="*" />
</tx:attributes>
</tx:advice>
Is that efficient for get*queries?
Because, as far I think, using transactions should be done like for CREATE, UPDATE, DELETEand such queries.
Am I missing something here?
这对get*查询有效吗？
因为，据我认为，使用事务应该像做CREATE，UPDATE，DELETE和这样的查询。
我在这里错过了什么吗？
回答by tjg184
Using transactions is somewhat dependent on the requirement.
使用事务在某种程度上取决于需求。
Obviously, using transactions on UPDATE and DELETE operations makes sense. Using transactions on SELECT statements could be useful too if, for example, you needed to lock the record such that another thread/request would not change the read. This would generally be a business requirement.
显然，在 UPDATE 和 DELETE 操作上使用事务是有道理的。例如，如果您需要锁定记录以便另一个线程/请求不会更改读取，则在 SELECT 语句上使用事务也可能很有用。这通常是业务需求。
At our company we do wrap all statements (i.e. SELECT, UPDATE, DELETE) in a transaction.
在我们公司，我们确实将所有语句（即 SELECT、UPDATE、DELETE）包装在一个事务中。
In addition, transactional management is really better suited at another layer in addition to the data level. Generally, transactions would match the business requirement. For example, if the requirement is to deposit money in an account, then some higher level class/code should be used to mark the entire method as transactional since that specific method needs to be completed as one unit (since there would likely be multiple database calls).
此外，事务管理确实更适合在数据层之外的另一层。通常，交易会与业务需求相匹配。例如，如果要求将钱存入帐户，则应使用一些更高级别的类/代码将整个方法标记为事务性，因为该特定方法需要作为一个单元完成（因为可能有多个数据库电话）。
Spring has much to say about transactional management.
Spring 对事务管理有很多话要说。
回答by John Kane
回答by Olaf
A good rule is to manage transactions at an application level above DAO. This way, if you have a data access operation A that some times need to be executed in own transaction and sometimes should join the existing transaction, you wouldn't have to jump through the hoops. Combine this approach with managing transactions (and Hibernate sessions) via AOP and watch your code grow more understandable and maintainable.
一个好的规则是在 DAO 之上的应用程序级别管理事务。这样，如果您有一个数据访问操作 A，有时需要在自己的事务中执行，有时应该加入现有事务，您就不必跳过箍了。将此方法与通过 AOP 管理事务（和 Hibernate 会话）相结合，并观察您的代码变得更易于理解和维护。
回答by Affe
To answer your specific question about getters:
要回答有关 getter 的具体问题：
If you use an AOP transaction with readOnly true, andyou properly set your JPA dialect to hibernate, Spring will put your Hibernate Session into no-flush mode. That can add up to substantial performance improvements for high volume operations by eliminating needless dirty-checks. So it is worthwhile in that regard.
如果您使用 readOnly 为 true 的 AOP 事务，并且您正确地将 JPA 方言设置为休眠，Spring 会将您的休眠会话置于非刷新模式。通过消除不必要的脏检查，这可以显着提高大容量操作的性能。所以在这方面是值得的。
