实体同步到连接的数据库交易 commit时间。如果你只有n = 1正在进行的事务（此处：JTA/容器管理），一个或多个实体的更改会在您调用时写入数据库flush() on the EntityManager实例。
但是，只有在负责事务处理的容器（此处为：Glassfish）正确执行事务后，更改才变得“可见”。供参考，请参阅。第 7.6.1 条（第 294 页）JPA 规范 2.0 http://download.oracle.com/otn-pub/jcp/persistence-2.0-fr-eval-oth-JSpec/persistence-2_0-final-spec.pdf?AuthParam=1480835603_31bc0b7c7f0ef760f3877bccf4716071其中定义：
新的持久化上下文begins当调用容器管理的实体管理器时（具体来说，当调用 EntityManager 接口的方法之一时）在活动 JTA 事务的范围内，并且当前不存在与 JTA 事务关联的持久性上下文。创建持久性上下文，然后将其与 JTA 事务关联。
持久化上下文ends当关联的 JTA 事务提交或回滚时，EntityManager 管理的所有实体都会分离。
在第 3.2.4 节（同步到数据库）中JPA 规范 2.0 http://download.oracle.com/otn-pub/jcp/persistence-2.0-fr-eval-oth-JSpec/persistence-2_0-final-spec.pdf?AuthParam=1480835603_31bc0b7c7f0ef760f3877bccf4716071我们发现：
持久实体的状态同步到数据库事务提交.
[..]
当事务处于活动状态时，持久性提供程序运行时也可以在其他时间执行与数据库的同步。这flush应用程序可以使用方法来force同步。
它适用于与持久性上下文关联的实体。这EntityManager和 Query setFlushMode 方法可用于控制同步语义。的效果FlushModeType.AUTO定义见第 3.8.7 节。如果FlushModeType.COMMIT指定后，刷新将在事务提交时发生；允许但不要求持久性提供者在其他时间执行刷新。如果没有活动的事务，则持久性提供程序不得刷新到数据库。
最有可能在您的场景中，容器（Glassfish）和/或您的应用程序配置为FlushModeType.COMMIT(*1)。以防万一FlushModeType.AUTO是否到位，取决于持久性提供程序 (EclipseLink)，“负责确保持久化上下文中所有实体的状态的所有更新（可能会影响查询结果）对于查询处理都是可见的。“（第 3.8.7 节，第 122 页）
相比之下，clear()方法本身不会提交任何内容。它只是将所有托管实体与当前持久性上下文分离，从而导致尚未刷新（提交）的实体上的任何更改丢失。如需参考，请参见第 17 页。 70 个链接JPA Spec http://download.oracle.com/otn-pub/jcp/persistence-2.0-fr-eval-oth-JSpec/persistence-2_0-final-spec.pdf?AuthParam=1480835603_31bc0b7c7f0ef760f3877bccf4716071.
相对于该OutOfMemoryError，很难说出在什么情况下导致这种情况的原因，因为您也没有提供太多详细信息。但是，我会：
- 阅读 JPA 规范的上述部分
- 检查您的环境配置方式以及
- 重新评估应用程序的编写/实现方式，可能会对正在运行的容器的事务处理做出错误的假设。
与 2. 相关，您可以检查您的persistence.xml是否配置
<property name="eclipselink.persistence-context.flush-mode" value="COMMIT" />
并将其更改为AUTO看看是否有什么不同。
希望能帮助到你。
脚注
*1: 但这是一个很好的猜测，因为您没有提供有关您的设置/环境的详细信息。
