WhizLabs wrote:If a JTA transaction is propagated into the stateful session bean to which an extended persistence context is bound but with the JTA bound persistence context is different, container throws an EJBException
Is this correct? I actually couldn't understand this.
It is correct. Here's why: suppose the SFSB has an extended persistent context, and then another transaction is started elsewhere, and a persistent context is bound to it, and eventually the call is made to the SFSB. Now, if the transaction is propagated to the SFSB (it might not be, if the SFSB method is TransactionAttributeType.NOT_SUPPORTED for example), there are 2 persistence contexts available - the original, extended context, and the new one, propagated with the transaction. There is a clash. Which one should the persistence provider pick and use? It is a hard decision, that hard to throw an exception, actually ;-)
Yes, there should be only one, but you have only one context for a transaction, and the second is the extended context that the SFSB had before, and which is bound to the lifecycle of the bean. So, there would effectivaly be 2 contexts.
That's probably because you are not invoking the entity manager in the first bean - the context is simply not created, as JTA contexts are created when first call to an EntityManager is made.
A new persistence context begins when the container-managed entity manager is invoked in the
scope of an active JTA transaction, and there is no current persistence context already associated with
the JTA transaction. The persistence context is created and then associated with the JTA transaction.
So, this would imply that you are propagating the transaction, but as no persistent context was created, it is not propagated.