何时在 Spring 和 Hibernate 中使用事务？
升级我的项目我在这里考虑交易。
好吧，问题是我不太确定何时应该在 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>
这对于 get* 有效吗？ 查询？
因为，据我认为，使用事务应该像 CREATE、UPDATE、DELETE 和此类查询一样完成。
我在这里错过了什么吗？
Upgrading my project I'm thinking here about transactions.
Well, the thing is I'm not quite sure when should I use the transactions for 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-only attribute?
<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, DELETE and such queries.
Am I missing something here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用事务在某种程度上取决于需求。
显然，在 UPDATE 和 DELETE 操作上使用事务是有意义的。例如，如果您需要锁定记录以便另一个线程/请求不会更改读取，则在 SELECT 语句上使用事务也可能很有用。这通常是业务需求。
在我们公司，我们确实将所有语句（即 SELECT、UPDATE、DELETE）包装在事务中。
此外，事务管理确实更适合数据级别之外的另一层。一般来说，交易会符合业务需求。例如，如果要求是将钱存入帐户，则应使用一些更高级别的类/代码将整个方法标记为事务性的，因为该特定方法需要作为一个单元完成（因为可能有多个数据库）来电）。
Spring 对于事务管理有很多话要说。
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.
At our company we do wrap all statements (i.e. SELECT, UPDATE, DELETE) in a transaction.
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.
一个好的规则是在 DAO 之上的应用程序级别管理事务。这样，如果您有一个数据访问操作 A，有时需要在自己的事务中执行，有时需要加入现有事务，那么您就不必跳过这些麻烦。将此方法与通过 AOP 管理事务（和 Hibernate 会话）相结合，您的代码将变得更加易于理解和维护。
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.
这似乎是一个相当不错的答案你应该。然而，这给出了一些不这样做的理由。基本上，如果您的修改未完成，数据可能最终处于错误状态，那么您希望使用它们。
This seems like a fairly decent answer of why you should. However, this gives some reasons not to. Basically, it you want to use them when data could end up in a bad state if your modifications are not completed.
回答关于 getter 的具体问题：
如果您使用 readOnly true 的 AOP 事务，并且您正确地将 JPA 方言设置为休眠，Spring 会将您的 Hibernate 会话置于 no-flush 模式。通过消除不必要的脏检查，可以显着提高大容量操作的性能。所以从这方面来说这是值得的。
To answer your specific question about getters:
If you use an AOP transaction with readOnly true, and you 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.