需要 EJB 3.1 Singleton + JPA + JSF 设计建议

给定：简单的 JSF web 应用程序（无 Seam），让 JSF bean 调用几个 EJB，而 EJB 又加载并保存 JPA 实体。我想要的是使用@Singletonejb 和注入的注释EntityManager 代替 EntityManagerFactory:

@Singleton
public class MyEJB {
  @PersistenceContext(unitName = PERSISTENCE_UNIT_NAME)
  protected EntityManager em; // not EntityManagerFactory
}

规格说@Singleton是线程安全的，支持并发和事务属性（从我的观点来看）这使得从 JSF bean 调用变得安全。我预计性能也会有所提高，因为EntityManager不会为每个调用重新创建，并且具有内部缓存功能。

我在这里主要关心的是当我有多个单例并且因此具有相同数量的长期生存的 EntityManager 时，对 JPA 实体的创建/更新操作。

• 如果一个单例更新 JPA 实例会发生什么以及这些如何发生 更改是否会填充到其他单例？
• 由于我无法关闭实体管理器，我是否需要刷新它 每个实体更新？
• 如果这几个单例共享同一个实体会更好吗 经理？
• 我只看到了很少的这种设计的例子。为什么？有没有严重的 缺点？

提前谢谢了！

我还期望性能上的提升，因为 EntityManager 不会为每个调用重新创建，而且它具有内部缓存功能。

您可能会使用单例节省一些内存，但在应用程序中的任何地方使用它实际上可能会使其速度变慢，因为由于只有一个 EJB 来服务应用程序的各个用户的所有并发请求，因此容器会锁定对 EJB 的访问，并且当它忙于处理一个请求，无法处理另一个请求。然而，使用锁类型（即，@Lock(WRITE) and @Lock(READ)).

当您想要使用 EJB 计时器定期执行一段代码或定期更新缓存等时，单例非常有用。

如果一个单例更新 JPA 实例会发生什么以及如何将这些更改填充到其他单例？

与非单例 EJB 的行为方式应该没有任何不同。

由于我无法关闭实体管理器，我是否需要在每次实体更新时刷新它？

如果您使用 CMT，则不会。在每笔交易结束时，所有内容都会自动刷新。

如果这几个单例共享同一个实体管理器会更好吗？

对我来说似乎是过早的优化。只需让容器为您注入 EM 即可。

我只看到了很少的这种设计的例子。为什么？有什么严重的缺点吗？

已经解释过了。