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

Question

给定:简单的 JSF webapp(没有 Seam)，让 JSF bean 调用几个 EJB，而这些 EJB 又加载和持久化 JPA 实体。我想要的是使用 @Singleton ejb 的注解和注入(inject) EntityManager 而不是 EntityManagerFactory :

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

规范说 @Singleton是线程安全的，支持并发和事务属性(来自我的 pov)使得从 JSF bean 调用变得安全。由于EntityManager，我还期望性能优势不会为每个调用重新创建，它是内部缓存功能。

我主要关心的是在我有几个单例的情况下对 JPA 实体的创建/更新操作，因此，长期存在的 EntityManager 数量相同。

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

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

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

我只看到了这种设计的几个例子。为什么？有没有严重的
缺点？

提前谢谢了!

Answer 1

I expect also performance benefits because of EntityManager not being recreated for each call and it's internal caching abilities.

您可能会使用单例来节省一些内存，但在您的应用程序中的任何地方使用它可能会使其实际上变慢，因为只有一个 EJB 可以为您的应用程序的各个用户提供所有并发请求，容器会锁定对 EJB 的访问以及何时忙于服务一个请求，它不能服务另一个请求。然而，使用锁类型(即 @Lock(WRITE) 和 @Lock(READ) )可以在一定程度上缓解这种情况。

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

What happens if one singleton updates an JPA instance and how these changes are populated to other singletons?

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

As I'm not able to close entity manager, do I need to flush it upon each entity update?

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

Would it be better if these few singletons will share the same entity manager?

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

I saw only few examples of such design. Why? Are there any serious drawbacks?

已经解释过了。