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

Question

给定:简单的JSF webapp(没有Seam),让JSF bean调用很少的EJB,然后加载并持久化JPA实体.我想要的是@Singleton为ejb 使用注释并注入EntityManager 而不是 EntityManagerFactory:

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

Spec说这@Singleton是线程安全的,支持并发和事务属性(从我的pov)可以安全地从JSF bean调用.我期望还有性能优势,因为EntityManager没有为每个调用重新创建它的内部缓存功能.

我主要担心的是在我有几个单身人士的情况下对JPA实体进行创建/更新操作,因此,相同数量的长生命EntityManagers.

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

提前谢谢了!

Answer 1

我期望还有性能优势,因为EntityManager没有为每个调用重新创建它的内部缓存功能.

你可以使用单例来节省一些内存,但是在应用程序的任何地方使用它都会使它实际上变慢,因为由于应用程序的各个用户只有一个EJB来处理所有并发请求,所以容器会锁定对EJB的访问权限.忙于提供请求,无法提供其他请求.然而,使用锁类型(即@Lock(WRITE)和@Lock(READ))可以在某种程度上缓解这种情况.

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

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

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

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

如果你使用CMT,没有.在每次交易结束时,所有内容都将自动刷新.

如果这些少数单身人士共享同一个实体经理会更好吗？

看起来对我来说过早优化.让容器为你注入EM.

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

已经解释过了.