需要EJB 3.1 Singleton + JPA + JSF设计建议 [英] EJB 3.1 Singleton + JPA + JSF design advice needed

问题描述

给出:简单的JSF webapp(没有Seam)，让JSF bean调用很少的EJB，这些EJB依次加载和持久化JPA实体.我要使用的是对ejb使用@Singleton批注并注入EntityManager 代替 EntityManagerFactory:

Given: simple JSF webapp (no Seam), having JSF beans calling few EJB's which in turn load and persist JPA entities. What I want to is to use @Singleton annotation for ejb's and inject EntityManager instead of EntityManagerFactory:

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

Spec表示@Singleton是线程安全的，支持并发和事务属性，这些属性(从我的pov看)使从JSF Bean调用安全.我希望由于不会为每个调用重新创建EntityManager及其内部缓存功能，因此也会带来性能上的好处.

Spec says that @Singleton is thread-safe, supports concurrency and transaction attributes which (from my pov) makes it safe for calling from JSF beans. I expect also performance benefits because of EntityManager not being recreated for each call and it's internal caching abilities.

在这里，我主要关心的是在我有多个单例并且因此拥有相同数量的长期EntityManager的情况下，对JPA实体的创建/更新操作.

My main concern here is create/update operations on JPA entities in the situation when I have several singletons and, as a result, the same count of long-living EntityManagers.

• 如果一个单例更新一个JPA实例会发生什么? 变化填充到其他单例中?
• 由于我无法关闭实体管理器，因此是否需要刷新它 每个实体都更新?
• 如果这几个单身人士共享同一个实体会更好 经理?
• 我只看到了这种设计的几个例子.为什么?有没有严重的 缺点?

• What happens if one singleton updates an JPA instance and how these changes are populated to other singletons?
• As I'm not able to close entity manager, do I need to flush it upon each entity update?
• Would it be better if these few singletons will share the same entity manager?
• I saw only few examples of such design. Why? Are there any serious drawbacks?

非常感谢！

推荐答案

由于没有为每个调用重新创建EntityManager及其内部缓存功能，我希望性能也会有所提高.

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))可以在某种程度上缓解这种情况.

You might save some memory using singletons, but using it everywhere in your app could make it actually slower, because as there's only one EJB to serve all the concurrent requests by various users of your app, the container locks access to the EJB and when it's busy serving a request it cannot be serving another request. However this can be alleviated to some degree using lock types (i.e. @Lock(WRITE) and @Lock(READ)).

当您想使用EJB计时器定期执行一段代码或定期更新高速缓存等时，单次请求很有用.

Singletons are useful for times when you want to execute a piece of code periodically using EJB timers, or to update a cache periodically, etc.

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

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

与非单例EJB的行为没什么不同.

Shouldn't be any different to the way non-singleton EJBs behave.

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

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

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

If you use CMT, no. At the end of each transaction everything will be flushed automatically.

如果这几个单身人士共享同一个实体管理器会更好吗?

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

对我来说好像过早的优化.只需让容器为您注入EM.

Looks like premature optimization to me. Just let the container inject the EM for you.

我只看到了这种设计的几个例子.为什么?有什么严重的弊端吗?

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

已经解释过了.

这篇关于需要EJB 3.1 Singleton + JPA + JSF设计建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！