这是一个设计问题，未提交具体代码来保护我的底部。
使用Hibernate时，标准工作流程如下：
可能会重复2-4次。
Session.clear（）的合理用例是什么？
答：我遇到的具体问题是一段（大型）代码，该代码可以加载和修改实体，然后清除（）会话，实质上是丢弃所做的更改。（要完成的业务任务不包括修改实体，因此代码“有效”）。
在我看来，正确的设计将是确保（大）代码段不进行不想保存的更改？
B：我猜想Session.clear（）的存在是为了方便/灵活，而不是因为使用它是一个好主意。
我是否误解了hibernate哲学？
C：子问题：框架代码在任务完成时无条件清除（）会话是否是个坏主意？恕我直言，如果任务完成后会话脏了，框架应该抱怨！任务完成后，应关闭该会话…（不考虑当前的性能）
（标签A，B和C，因此您可以指明要回答的部分）。
广告。 答：看起来您知道该怎么clear()做。显式调用它的原因是从L1高速缓存中删除所有受管实体，以便在一个事务中处理大型数据集时，它不会无限增长。
clear()
它丢弃了对 未明确 保留的托管实体所做的所有更改。这意味着您可以安全地修改实体，显式更新实体并清除会话。这是 正确的 设计。显然，如果不进行任何更改（长时间但只读的会话），clear()则始终是安全的。
您还可以使用无状态会话。
广告。 B：不，存在上述原因：确保L1（会话缓存）不会增长太多。当然，手动维护它不是一个好主意，这表明应该对大型数据集使用另一种工具，但是有时这是必须的。
请注意，在JPA规范中也有clear()和flush()方法。在这种情况下，应始终flush()先调用，然后再将更改推送到数据库中（显式更新）clear()。
flush()
广告。 C：当用户清除带有脏更改的会话时，警告用户（也许通过发出警告消息而不是引发异常）实际上是一个好主意。另外，我不认为 框架 代码应该clear()无条件调用，除非可以确保 框架 代码中的用户代码刷新或不进行任何更改。
