EJB 3.x : extended or transaction-scoped EnityManager with EntityManagerFactory

Question

Trying to figure out some possible situations, when a EntityManagerFactory could be useful in EJB. Of course usually one needs just an transaction-scoped EntityManager (JTA scoped), so that all injected EntityManagers share the same PersistenceContext. What happens in the following situations:

When @PersistenceContext(type=PersistenceContextType.EXTENDED) is used: is this JTA-enabled? will the requests of such an EntityManager be executed in the context of the JTA? If not, that in which one? (Note: of course it works only with @Stateful EJBs). Of course it is clear, that in this case the EntityManager will have its own/special PersistenceContext.
When one uses @PersistenceUnit to get a EntityManagerFactory in an EJB (I suppose it works in all type of EJBs, correct?), is the obtained Entitymanager JTA-enabled (of course Entitymanager.joinTransaction() is necessary)? How can one get a transaction-scoped (JTA enabled) or Extended EntityManager from the Factory? When would be useful to use the Factory, instead of a Entitymanager. (Of course it is clear that an EntityManagerFactory is the only interface for a Java SE application to the JPA, but what about EJB?).

I recommend getting a book on EJB. This one is good: shop.oreilly.com/product/9780596158033.do. If you don't understand the difference, you probably just want to use a PersistenceContext. Chances are you'll know if you need the alternative. — jahroy
what was the question again? I see several questions, some of them self-answered, not all correctly. Was the essential question when to use an extended persistence context in a JEE application? — kostja
@jahroy this is the book I read. Just trying to figure out some things. So far almost everything I needed was the @PersistenceContext annotation. Again: I just was trying to figure some things out... — Andrei I
@kostja Yes, I have more questions. I expect some confirmations/corrections to my afirmations & the answers to my questions... — Andrei I

Sym-Sym Sym-Sym · Accepted Answer · 2012-11-21T02:16:26

Your questions revolve around the assumption that you are put in a situation were you are obliged to inject @PersistenceUnit to get a EntityManagerFactory in an EJB. Well... let me narrate some missing background here:

In servlets

We had to follow these steps in order to instantiate an EntityManager:

Inject @PersistenceUnit to obtain an EntityManagerFactory
Use the line: entityManager = entityManagerFactory.createEntityManager();

The above 2 steps quarantees the EntityManager is local to the current thread thus thread-safe. This scenario was a workaround for servlets being re-entrant with respect to the container injection. Meaning the servlet will accept already existing entityManagers to be injected by the container.

In EJBs

By definition, EJBs are non-reentrant with respect to the container injection, thus we know that the container will instantiate a fresh entityManager proxy local for the EJB, thus thread-safe.

That said we can take the discussion into how/when to use Extended PersistenceContext

Quoting the JSR-317 of the JPA specifications page 294:

A container-managed extended persistence context can only be initiated within the scope of a stateful session bean. It exists from the point at which the stateful session bean that declares a dependency on an entity manager of type PersistenceContextType.EXTENDED is created, and is said to be bound to the stateful session bean... The persistence context is closed by the container when the @Remove method of the stateful session bean completes (or the stateful session bean instance is otherwise destroyed).

Thus the non-reentrancy feature can be broke using the attribute PersistenceContextType.EXTENDED only to serve the stateful session bean semantics. It is mandatory for the stateful session bean to maintain the very same EntityManager as long as it exists.

To conclude

In your first question:

when a EntityManagerFactory could be useful in EJB?

the answer is: It is not useful.

As for your second question I am sure the first answer and the above background narration discards the need to ask it in the first place!