org.hibernate.Session.clear() 被认为是有害的? [英] org.hibernate.Session.clear() considered Harmful?

查看:28
本文介绍了org.hibernate.Session.clear() 被认为是有害的?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是一个设计问题,为了保护我的底部,没有提交具体代码.

使用 Hibernate 时的标准工作流程如下:

  1. 公开会议
  2. 开始交易
  3. 开展业务(读取和修改数据)
  4. 提交交易
  5. 闭幕式

可能有 2-4 次迭代.

Session.clear() 的合理用例是什么?

A:我遇到的具体问题是一段(大)代码,它加载和修改实体,然后清除()会话,基本上丢弃所做的更改.(要完成的业务任务不包括修改实体,所以代码有效").

在我看来,正确的设计是确保(大)代码段不会进行它不想保存的更改?

B:我猜 Session.clear() 的存在是为了方便/灵活,而不是因为使用它是个好主意.

我是否误解了 Hibernate 的哲学?

C:子问题:框架代码在任务完成时无条件清除()会话是一个坏主意吗?恕我直言,如果任务完成时会话很脏,框架应该抱怨!会话应该关闭,因为任务完成了......(不考虑一分钟的表现)

(标记 A、B 和 C,以便您可以指出您正在回答的部分).

解决方案

广告.A:看起来您知道 clear() 的作用.显式调用它的原因是将所有托管实体从 L1 缓存中移除,以便在一个事务中处理大数据集时不会无限增长.

它会丢弃对未明确持久化的托管实体所做的所有更改.这意味着您可以安全地修改实体、显式更新它并清除会话.这是正确的设计.显然,如果没有进行任何更改(长但只读会话),clear() 总是安全的.

您也可以使用无状态会话.

广告.B:不,它存在的原因如上:确保L1(会话缓存)不会增长太多.当然,手动维护它是一个糟糕的主意,并且表明应该使用其他工具来处理大型数据集,但有时它是必须的.

请注意,在 JPA 规范中还有 clear()flush() 方法.在这种情况下,您应该始终先调用 flush() 将更改推送到数据库中(显式更新),然后再调用 clear().

广告.C:当他/她用脏更改清除会话时警告用户(可能通过发出警告消息而不是抛出异常)实际上是一个好主意.此外,我不认为 framework 代码应该无条件地调用 clear() ,除非确定它运行的用户代码刷新或不进行任何更改.

This is a design question, concrete code not submitted to protect my bottom.

When working with Hibernate the standard workflow is as follows:

  1. Open Session
  2. Start Transaction
  3. Do the business (read and modify data)
  4. Commit Transaction
  5. Close Session

with possibly iterations through 2-4.

What are reasonable use cases for Session.clear()?

A: The concrete problem I have is a (big) piece of code which loads and modifies entities, then clear()s the session, essentially throwing away the changes that were made. (The business task to be accomplished does not include modifying the entities, so the code "works").

Seems to me the right design would be to make sure the (big) piece of code does not make changes it does not want to save?

B: I would guess Session.clear() exists for convenience/flexibility, not because it is a good idea to use it.

Have I misunderstood the Hibernate philosophy?

C: Subquestion: Is it a bad idea for framework code to unconditionally clear() the session when a task completes? IMHO, the framework should complain if the session is dirty when a task completes! The session should be closed, seeing as the task is done... (Disregarding performance for the minute)

(Labels A, B and C so you can indicate which part you are answering).

解决方案

Ad. A: Looks like you are aware what clear() does. The reason to call it explicitly is to remove all managed entities from L1 cache, so that it does not grow infinitely when processing large data sets in one transaction.

It discards all the changes that were made to managed entites not explicitly persisted. This means that you can safely modify an entity, update it explicitly and clear the session. This is the right design. Obviously if no changes are made (long, but read only session), clear() is always safe.

You can also use stateless sessions.

Ad. B: No, it exists for the reasons above: to make sure L1 (session cache) does not grow too much. Of course maintaining it manually is a poor idea and an indication that another tool should be used for large data sets, but sometimes it is a must.

Note that in JPA specification there is also clear() and flush() method. In this case you should always call flush() first to push changes into the database (explicit update) prior to calling clear().

Ad. C: It's actually a good idea to warn the user (maybe by issuing warning message rather than throwing an exception) when he/she clears the session with dirty changes. Also I don't think a framework code should call clear() unconditionally, unless it is sure that the user code it runs flushes or does not make any changes.

这篇关于org.hibernate.Session.clear() 被认为是有害的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆