Remote client with UserTransaction fails on 2nd SFSB invocation when using extended PC

[ahaumer]

I'm about to port a JBAS51 application to JBAS7 and I have troubles with our remote clients.

On the server I have several DAO SFSB which all get an extended persistence context injected like this:

    @PersistenceContext(unitName=PERSISTENCE_UNIT_NAME, type=PersistenceContextType.EXTENDED)
    public void setEntityManager(final EntityManager entityManager)
    {
        this.em = entityManager;
    }

All SFSB are packaged inside an EAR which is deployed on the server.

On the remote client I'm using a UserTransaction to start a transaction, then call some EJB methods.

Here's a simple junit test case, stripped down to the essential code demonstrating the problem:

public class MyAppTest
{

    @Test
    public void test() throws Exception
    {
        InitialContext ctx = new InitialContext();
        OrganisationDAO oDAO = (OrganisationDAO)ctx.lookup("ejb:myapp/dao//OrganisationDAO!myapp.dao.OrganisationDAORemote?stateful");
        PersonDAO pDAO = (PersonDAO)ctx.lookup("ejb:myapp/dao//PersonDAO!myapp.dao.PersonDAORemote?stateful");
        UserTransaction ut = EJBClient.getUserTransaction("integrationTest");

        ut.begin();

        oDAO.someMethod();
       
        // The test fails on the following method invocation
        pDAO.anotherMethod();
    }

}

With JBAS 7.1.1.Final (as well as 7.2.0.Final) the call to pDAO.count() results in the following error:

Caused by: javax.ejb.EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=myapp.ear#myappPU, persistence context already in transaction =ExtendedEntityManager [myapp.ear#myappPU], extended persistence context =ExtendedEntityManager [myapp.ear#myappPU].
        at org.jboss.as.jpa.container.ExtendedEntityManager.internalAssociateWithJtaTx(ExtendedEntityManager.java:126) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.as.jpa.container.SFSBCallStack.pushCall(SFSBCallStack.java:159) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:56) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
        at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
        at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:202) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
        ... 27 more

With JBAS51 this test works fine (other JNDI lookup strings and UserTransaction setup code of course)

With JBAS7, it works only if I either do not start a transaction on the client or do not use an extended PC on the server.

But that is exactly what I want to do: control the transaction on the client and still use an extended PC on the server.

What am I missing here?

I suppose this is still a supported use case, isn't it?

[ahaumer]

I did investigate this problem further and it seems this is actually behavior according to the specification...

The exception comes from the ExtendedEntityManager#internalAssociateWithJtaTx()

This method is called when the AS tries to inject an XPC, the relevant code looks like this:

        // ensure that a different XPC (with same name) is not already present in the TX
        if (isInTx) {

            // 7.6.3.1 throw EJBException if a different persistence context is already joined to the
            // transaction (with the same puScopedName).
            EntityManager existing = TransactionUtil.getTransactionScopedEntityManager(puScopedName);
            if (existing != null && existing != this) {
                // should be enough to test if not the same object
                throw MESSAGES.cannotUseExtendedPersistenceTransaction(puScopedName, existing, this);
            } else if (existing == null) {
                // JPA 7.9.1 join the transaction if not already done.
                TransactionUtil.registerExtendedUnderlyingWithTransaction(puScopedName, this, underlyingEntityManager);
            }
        }

So I have the following situation: A client starts a UserTransaction spanning several method invocations on stateful session beans

On the first invocation of the first bean an XPC is associated with the transaction.

On the first invocation of the second bean, another XPC from the same PU is created. The second XPC is a different object, though, so (existing != this) is true and the exception is thrown.

The relevant code in ExtendedEntityManager#internalAssociateWithJtaTx() refers to the JPA 2.0 specification which reads like this (relevant part of section 7.6.3.1):

<quote>

If a component is called and the JTA transaction is propagated into that component:

• If the component is a stateful session bean to which an extended persistence context has been bound and there is a different persistence context bound to the JTA transaction, an EJBException is thrown by the container.

• Otherwise, if there is a persistence context bound to the JTA transaction, that persistence context is propagated and used.

</quote>

IMHO, the interesting question is, what does "a different persistence context" really mean?

From the application's point of view, all beans use the same persistence unit name and thus should use the same persistence context.

The interpretation of the specification as it is currently implemented in JBAS7 means, that it is not possible for a client to start a transaction and then call several SFSB using XPC.

This definitely did work with JEE5, we have several applications running on JBoss AS 5.1 using this use case.

I have now several questions on my mind:

* Is my analysis correct?

* If yes: Is the implementation in JBAS7 in this special case according to the specification or could it be interpreted (and thus implemented) differently?

* If yes: What is the reason behind this specified behavior?

* If this is all "as specified": How am I supposed to implement this use case now? After all, this did work with JEE5 without problems!

[smarlow]

Could you also try with the latest WildFly 8 (nightly) build.  The download link is here.  I am also interested in how your application works with the latest EAP 6.x release (download link is here).

To gather more information, could you also enable TRACE logging for org.jboss.as.jpa.  The instructions for enabling logging are here for WF8.  The AS7 instructions are here (will also work with EAP 6.x).

I'll try to answer your questions after you switch to EAP 6 or WildFly and provide the trace output which will help me answer to answer your questions.  I want to say that your hitting a bug that is fixed in later versions but lets wait for the results...

Scott

[smarlow]

I don't think you are hitting a bug.  It still might be interesting to try the later AS versions (EAP 6.x or WildFly 8.0).

IMHO, the interesting question is, what does "a different persistence context" really mean?

From the application's point of view, all beans use the same persistence unit name and thus should use the same persistence context.

"A different persistence context" can mean two possible things.

1. A transaction scoped persistence context (with the same persistence unit name) is already associated with the active JTA transaction and we are attempting to invoke a stateful bean that has an extended persistence context with the same persistence unit name.  You are not hitting this case.
2. An extended transaction scoped persistence context (with the same persistence unit name) is already associated with the active JTA transaction and we are attempting to invoke a stateful bean that has an extended persistence context with the same persistence unit name.  This is what you are experiencing.

I have now several questions on my mind:

* Is my analysis correct?

* If yes: Is the implementation in JBAS7 in this special case according to the specification or could it be interpreted (and thus implemented) differently?

* If yes: What is the reason behind this specified behavior?

* If this is all "as specified": How am I supposed to implement this use case now? After all, this did work with JEE5 without problems!

When you create the two remote bean instances, the creation of each remote bean will be done in isolation and no sharing of the extended persistence context will occur.  When the stateful beans are later invoked under the same JTA transaction, they would conflict with each other, which is why the error is thrown.

Your description of the issue is close to being correct, except its not calling the different beans that is the problem, it is the instantiation of each different bean that gets a different extended persistence context per bean.

In terms of your other question as to could this be handled differently, I'm not sure yet. 

A related discussion on the JPA 2.1 expert group mailing list is here.

Documentation on two different extended persistence context inheritance modes (neither of which cover your case) are described here. 

In terms of your questions about what you could do next.  If you change the remote client to only instantiate one remote stateful bean (masterSFSB) and have the multiple stateful beans injected into masterSFSB (locally), masterSFSB and its children (injected local) beans, can share the same extended persistence context.

For portability reasons, you should reference the extended persistence context from masterSFSB as well (not that you have to on AS 7/WildFly8/EAP6.x but other EE implementations do require this).  See the discussion of DEEP versus SHALLOW inheritance in the above doc link (about different inheritance modes).

Scott

[smarlow]

When you have time to consider my suggestions, I look forward to hearing of your progress on this (even if you reject them).  I'm not making any promises but am curious if we could introduce some changes in the future that would allow the old extended persistence context inheritance behaviour that you are depending on.

Keep us informed as to your progress.  Even though you are the first to report this, you probably won't be the last. 

From the application's point of view, all beans use the same persistence unit name and thus should use the same persistence context.

I intended to say that this applies within a JTA transaction. 

[ahaumer]

Scott,

many thanks for your answers!

I'm currently on a business trip and don't have time to work on this issue right now.

I'll be back today evening and will then try all things you suggested.

I'll keep you updated as soon as possible.

Thank you!

[ahaumer]

Hi!

I now did a test with the latest WildFly 8.0.0.Beta2-SNAPSHOT (from November, 8th).

To reproduce the problemt, I created a simple test application packaged in an EAR: two SFSB with just a simple "helloWorld" method.

Both SFSB get an XPC with the same unit name injected (but don't actually use the EntityManager for database operations as this is not necessary to show the problem)

The beans look like this:

Test1Bean

package xpctest;

import javax.ejb.Stateful;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.PersistenceContextType;

@Stateful
public class Test1Bean implements Test1
{
    @PersistenceContext(unitName="xpctestPU",type=PersistenceContextType.EXTENDED)
    EntityManager em;
       
    public String helloWorld(String name)
    {
        return "Hello world, hello " + name + ", from TestBean1";
    }
}

and Test2Bean:

package xpctest;

import javax.ejb.Stateful;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.PersistenceContextType;

@Stateful
public class Test2Bean implements Test2
{
    @PersistenceContext(unitName="xpctestPU",type=PersistenceContextType.EXTENDED)
    EntityManager em;
       
    public String helloWorld(String name)
    {
        return "Hello world, hello " + name + ", from TestBean2";
    }
}

I use the ExampleDS from the stock WildFly distribution as data source.

My persistence.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1"
             xmlns="http://xmlns.jcp.org/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
                                 http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
    <persistence-unit name="xpctestPU">
      <jta-data-source>java:/jboss/datasources/ExampleDS</jta-data-source>
    </persistence-unit>
</persistence>

(I don't really use the database in my beans, I just need the persistence unit for the XPC)

I started the wildfly server with the option -Djboss.node.name=xpctest to make the EJBClient.getUserTransaction() method happy.

I also created a simple remote client:

package main;
import java.util.Hashtable;

public class Main {
    public static void main(String[] args) throws Exception
    {
        final Hashtable<String,Object> jndiProperties = new Hashtable<String,Object>();
        jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
        InitialContext ctx = new InitialContext(jndiProperties);
        Test1 bean1 = (Test1)ctx.lookup("ejb:xpc-wildfly/xpc-wildfly-beans//Test1Bean!xpctest.Test1?stateful");
        Test2 bean2 = (Test2)ctx.lookup("ejb:xpc-wildfly/xpc-wildfly-beans//Test2Bean!xpctest.Test2?stateful");
        ctx.close();

        UserTransaction ut = EJBClient.getUserTransaction("xpctest");
       
        ut.begin();
           
        System.out.println(bean1.helloWorld("Andreas"));
        System.out.println(bean2.helloWorld("Andreas"));
           
        ut.rollback();
    }
}

On the client I use the following jboss-ejb-client.properties:

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false 
remote.connections=default 
remote.connection.default.host=localhost
remote.connection.default.port=8080 
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false 
remote.connection.default.username=andreas
remote.connection.default.password=mypwd

Nothing special here...

Running this client against wildfly-8.0.0.Beta2-SNAPSHOT gives the well known exception when bean2.helloWorld() is invoked on the client.

I enabled TRACE logging on the server and got the following log messages:

2013-11-12 12:53:49,745 DEBUG [org.jboss.as.ejb3] (Remoting "xpctest" task-4) Client with protocol version 2 and marshalling strategy river trying to communicate on Channel ID 33d41e69 (inbound) of Remoting connection 5cfe2ace to /127.0.0.1:35599
2013-11-12 12:53:49,751 DEBUG [org.jboss.as.ejb3] (Remoting "xpctest" task-4) Sending initial module availability message, containing 2 module(s) to channel Channel ID 33d41e69 (inbound) of Remoting connection 5cfe2ace to /127.0.0.1:35599
2013-11-12 12:53:49,754 DEBUG [org.jboss.as.ejb3] (Remoting "xpctest" task-4) Writing out cluster formation message for 0 clusters, to channel Channel ID 33d41e69 (inbound) of Remoting connection 5cfe2ace to /127.0.0.1:35599
2013-11-12 12:53:49,804 TRACE [org.jboss.as.jpa.messages] (EJB default - 1) JPAService.getDefaultExtendedPersistenceInheritance() == DEEP
2013-11-12 12:53:49,881 DEBUG [org.jboss.as.jpa] (EJB default - 1) created new ExtendedEntityManager for unit name=xpc-wildfly.ear#xpctestPU, useDeepInheritance = true
2013-11-12 12:53:50,079 TRACE [org.jboss.as.jpa.messages] (EJB default - 2) JPAService.getDefaultExtendedPersistenceInheritance() == DEEP
2013-11-12 12:53:50,080 DEBUG [org.jboss.as.jpa] (EJB default - 2) created new ExtendedEntityManager for unit name=xpc-wildfly.ear#xpctestPU, useDeepInheritance = true
2013-11-12 12:53:50,197 DEBUG [org.jboss.as.ejb3] (EJB default - 3) Looking for stateful component instance with session id: {[75, 101, 4, 119, 53, -121, 72, -125, -117, 49, 28, -3, 63, 89, -31, -56]}
2013-11-12 12:53:50,217 DEBUG [org.jboss.as.ejb3] (EJB default - 4) Looking for stateful component instance with session id: {[14, -99, 50, -39, 7, -76, 71, 89, -77, -107, -93, 77, 8, -29, -24, 14]}
2013-11-12 12:53:50,223 ERROR [org.jboss.as.ejb3] (EJB default - 4) javax.ejb.EJBTransactionRolledbackException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=xpc-wildfly.ear#xpctestPU, persistence context already in transaction =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], extended persistence context =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU].
2013-11-12 12:53:50,228 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 4) JBAS014134: EJB Invocation failed on component Test2Bean for method public abstract java.lang.String xpctest.Test2.helloWorld(java.lang.String): javax.ejb.EJBTransactionRolledbackException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=xpc-wildfly.ear#xpctestPU, persistence context already in transaction =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], extended persistence context =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU].
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
        at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
        at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
        at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
        at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
        at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: javax.ejb.EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=xpc-wildfly.ear#xpctestPU, persistence context already in transaction =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], extended persistence context =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU].
        at org.jboss.as.jpa.container.ExtendedEntityManager.internalAssociateWithJtaTx(ExtendedEntityManager.java:133) [wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.as.jpa.container.SFSBCallStack.pushCall(SFSBCallStack.java:151) [wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:54) [wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:127) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        ... 39 more

2013-11-12 12:53:50,307 DEBUG [org.jboss.as.ejb3] (default I/O-3) Channel Channel ID 33d41e69 (inbound) of Remoting connection 5cfe2ace to /127.0.0.1:35599 closed

So wildfly basically shows the same behavior as JBAS71 and JBAS72 for this use case.

Just as a reference, I did the same test with JBoss 5.1.0.GA. The JEE application is almost the same, only the persistence descriptor had to be changed (different XML namespace and I use the JBoss 5 DefaultDS as datasource)

The client code had to be changed a little, too (different lookups of session beans and user transaction):

package main;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.transaction.UserTransaction;

import xpctest.Test1;
import xpctest.Test2;

public class Main {
    public static void main(String[] args) throws Exception
    {
        Context ctx = new InitialContext();
       
        UserTransaction ut = (UserTransaction)ctx.lookup("UserTransaction");

        Test1 bean1 = (Test1)ctx.lookup("xpc-jbas51/Test1Bean/remote-xpctest.Test1");
        Test2 bean2 = (Test2)ctx.lookup("xpc-jbas51/Test2Bean/remote-xpctest.Test2");
       
        ut.begin();
           
        System.out.println(bean1.helloWorld("Andreas"));
        System.out.println(bean2.helloWorld("Andreas"));
           
        ut.rollback();
    }
}

Instead of jboss-ejb-client.properties I use a jndi.properties resource file with the following content:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost:1099

So, nothing special here, too.

But this just runs fine against JBoss 5.1.0.GA and gives the expected results:

Hello world, hello Andreas, from TestBean1
Hello world, hello Andreas, from TestBean2

In the JBoss 5.1 logfile I find the following messages (DEBUG enabled):

2013-11-12 12:49:08,602 DEBUG [org.jboss.ejb3.common.registrar.plugin.mc.Ejb3McRegistrar] (WorkerThread#0[127.0.0.1:58498]) Returning from name "jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test1Bean,service=EJB3": jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test1Bean,service=EJB3
2013-11-12 12:49:08,722 DEBUG [org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory] (WorkerThread#0[127.0.0.1:58498]) Creating advice org.jboss.ejb3.remoting.IsLocalInterceptor with loader null
2013-11-12 12:49:08,724 DEBUG [org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory] (WorkerThread#0[127.0.0.1:58498]) Creating advice org.jboss.ejb3.security.client.SecurityClientInterceptor with loader null
2013-11-12 12:49:08,727 DEBUG [org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory] (WorkerThread#0[127.0.0.1:58498]) Creating advice org.jboss.aspects.tx.ClientTxPropagationInterceptor with loader null
2013-11-12 12:49:08,730 DEBUG [org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory] (WorkerThread#0[127.0.0.1:58498]) Creating advice org.jboss.aspects.remoting.InvokeRemoteInterceptor with loader null
2013-11-12 12:49:08,777 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#0[127.0.0.1:58498]) WorkerThread#0[127.0.0.1:58498] closed socketWrapper: ServerSocketWrapper[Socket[addr=/127.0.0.1,port=58498,localport=3873].349c9e9d]
2013-11-12 12:49:08,788 DEBUG [org.jboss.ejb3.common.registrar.plugin.mc.Ejb3McRegistrar] (WorkerThread#0[127.0.0.1:58499]) Returning from name "jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test2Bean,service=EJB3": jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test2Bean,service=EJB3
2013-11-12 12:49:08,799 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#0[127.0.0.1:58499]) WorkerThread#0[127.0.0.1:58499] closed socketWrapper: ServerSocketWrapper[Socket[addr=/127.0.0.1,port=58499,localport=3873].1692e684]
2013-11-12 12:49:08,954 DEBUG [org.jboss.ejb3.stateful.StatefulContainer] (WorkerThread#0[127.0.0.1:58501]) Received dynamic invocation for method with hash: 1565891452170378145
2013-11-12 12:49:08,984 DEBUG [org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor] (WorkerThread#0[127.0.0.1:58501]) ++++ LongLivedSessionPropagationInterceptor
2013-11-12 12:49:08,990 DEBUG [org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory] (WorkerThread#0[127.0.0.1:58501]) Creating advice InterceptorsFactory
2013-11-12 12:49:08,997 WARN  [org.jboss.ejb3.interceptors.aop.InterceptorsFactory] (WorkerThread#0[127.0.0.1:58501]) EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
2013-11-12 12:49:08,999 WARN  [org.jboss.ejb3.interceptors.aop.InterceptorsFactory] (WorkerThread#0[127.0.0.1:58501]) EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
2013-11-12 12:49:08,999 DEBUG [org.jboss.aop.microcontainer.beans.GenericBeanAspectFactory] (WorkerThread#0[127.0.0.1:58501]) Creating advice InjectInterceptorsFactory
2013-11-12 12:49:09,002 DEBUG [org.jboss.ejb3.interceptors.aop.InjectInterceptorsFactory] (WorkerThread#0[127.0.0.1:58501]) new InjectInterceptorsFactory
2013-11-12 12:49:09,002 DEBUG [org.jboss.ejb3.interceptors.aop.InjectInterceptorsFactory] (WorkerThread#0[127.0.0.1:58501]) Create interceptor chain for org.jboss.ejb3.aop.ExtendedManagedObjectAdvisor@2119304540 on public java.lang.String xpctest.Test1Bean.helloWorld(java.lang.String)
2013-11-12 12:49:09,005 DEBUG [org.jboss.ejb3.interceptors.aop.InjectInterceptorsFactory] (WorkerThread#0[127.0.0.1:58501]) Create interceptor chain for org.jboss.ejb3.aop.ExtendedManagedObjectAdvisor@2119304540 on public java.lang.String xpctest.Test1Bean.helloWorld(java.lang.String)
2013-11-12 12:49:09,006 DEBUG [org.jboss.ejb3.interceptors.aop.InterceptorSequencer] (WorkerThread#0[127.0.0.1:58501]) aroundInvoke [advisedMethod=public java.lang.String xpctest.Test1Bean.helloWorld(java.lang.String), unadvisedMethod=public java.lang.String xpctest.Test1Bean.helloWorld(java.lang.String), metadata=[metaData={DISPATCHER={OID=[type=AS_ISvalue=jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test1Bean,service=EJB3]}, REMOTING={SUBSYSTEM=[type=AS_ISvalue=AOP], INVOKER_LOCATOR=[type=AS_ISvalue=InvokerLocator [socket://ahnote.intern.xss.co.at:3873/?]]}, SFSBInvocation={SessionID=[type=AS_ISvalue=3j002-5zyv4e-hnx2sft6-1-hnx2uhdt-9r]}, security={context=[type=MARSHALLEDvalue=[org.jboss.security.plugins.JBossSecurityContext()CLIENT)]]}, IS_LOCAL={GUID=[type=AS_ISvalue=jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test1Bean,service=EJB3,VMID=fc611e52ee404dd8:-21a87fc:1424c236f83:-7ff9]}, TransactionPropagationContext={TransactionPropagationContext=[type=MARSHALLEDvalue=7f000002:ed2c:52821575:63]}, SessionInvocation={InvokedMethod=[type=AS_ISvalue=xpctest.Test1: xpctest.Test1.helloWorld(java.lang.String)]}}], targetObject=xpctest.Test1Bean@7d7d4013, arguments=[Ljava.lang.Object;@5def8919]
2013-11-12 12:49:09,013 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1[127.0.0.1:38474]) WorkerThread#1[127.0.0.1:38474] closed socketWrapper: ServerSocketWrapper[Socket[addr=/127.0.0.1,port=38474,localport=4446].342139e7]
2013-11-12 12:49:09,018 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#0[127.0.0.1:58501]) WorkerThread#0[127.0.0.1:58501] closed socketWrapper: ServerSocketWrapper[Socket[addr=/127.0.0.1,port=58501,localport=3873].7a661e12]
2013-11-12 12:49:09,025 DEBUG [org.jboss.ejb3.stateful.StatefulContainer] (WorkerThread#2[127.0.0.1:58502]) Received dynamic invocation for method with hash: 1565891452170378145
2013-11-12 12:49:09,027 DEBUG [org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor] (WorkerThread#2[127.0.0.1:58502]) ++++ LongLivedSessionPropagationInterceptor
2013-11-12 12:49:09,027 WARN  [org.jboss.ejb3.interceptors.aop.InterceptorsFactory] (WorkerThread#2[127.0.0.1:58502]) EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
2013-11-12 12:49:09,028 WARN  [org.jboss.ejb3.interceptors.aop.InterceptorsFactory] (WorkerThread#2[127.0.0.1:58502]) EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container
2013-11-12 12:49:09,028 DEBUG [org.jboss.ejb3.interceptors.aop.InjectInterceptorsFactory] (WorkerThread#2[127.0.0.1:58502]) Create interceptor chain for org.jboss.ejb3.aop.ExtendedManagedObjectAdvisor@137371982 on public java.lang.String xpctest.Test2Bean.helloWorld(java.lang.String)
2013-11-12 12:49:09,028 DEBUG [org.jboss.ejb3.interceptors.aop.InjectInterceptorsFactory] (WorkerThread#2[127.0.0.1:58502]) Create interceptor chain for org.jboss.ejb3.aop.ExtendedManagedObjectAdvisor@137371982 on public java.lang.String xpctest.Test2Bean.helloWorld(java.lang.String)
2013-11-12 12:49:09,028 DEBUG [org.jboss.ejb3.interceptors.aop.InterceptorSequencer] (WorkerThread#2[127.0.0.1:58502]) aroundInvoke [advisedMethod=public java.lang.String xpctest.Test2Bean.helloWorld(java.lang.String), unadvisedMethod=public java.lang.String xpctest.Test2Bean.helloWorld(java.lang.String), metadata=[metaData={DISPATCHER={OID=[type=AS_ISvalue=jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test2Bean,service=EJB3]}, REMOTING={SUBSYSTEM=[type=AS_ISvalue=AOP], INVOKER_LOCATOR=[type=AS_ISvalue=InvokerLocator [socket://ahnote.intern.xss.co.at:3873/?]]}, SFSBInvocation={SessionID=[type=AS_ISvalue=3j002-5zyv4e-hnx2sft6-1-hnx2uhis-9s]}, security={context=[type=MARSHALLEDvalue=[org.jboss.security.plugins.JBossSecurityContext()CLIENT)]]}, IS_LOCAL={GUID=[type=AS_ISvalue=jboss.j2ee:ear=xpc-jbas51.ear,jar=xpc-jbas51-beans.jar,name=Test2Bean,service=EJB3,VMID=fc611e52ee404dd8:-21a87fc:1424c236f83:-7ff9]}, TransactionPropagationContext={TransactionPropagationContext=[type=MARSHALLEDvalue=7f000002:ed2c:52821575:63]}, SessionInvocation={InvokedMethod=[type=AS_ISvalue=xpctest.Test2: xpctest.Test2.helloWorld(java.lang.String)]}}], targetObject=xpctest.Test2Bean@48e84a86, arguments=[Ljava.lang.Object;@327a53f9]
2013-11-12 12:49:09,039 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#2[127.0.0.1:58502]) WorkerThread#2[127.0.0.1:58502] closed socketWrapper: ServerSocketWrapper[Socket[addr=/127.0.0.1,port=58502,localport=3873].418d1a50]
2013-11-12 12:49:09,058 DEBUG [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1[127.0.0.1:38477]) WorkerThread#1[127.0.0.1:38477] closed socketWrapper: ServerSocketWrapper[Socket[addr=/127.0.0.1,port=38477,localport=4446].154e3e6e]

I did all tests directly in Eclipse to keep things simple. I'll attach a tar archive of the complete Eclipse projects so you should be able to reproduce the behavior easily.

So, how can we proceed?

Do you still want me to test this with EAP 6, too?

(I surely can do this, it's just a question of "will this give us additional information" and "is it worth the effort?")

For our application (and I'm sure this is not an exotic one) it is fundamental to have the ability to control transactions involving more than one SFSB with XPC on the server from a remote client.

Our business logic is implemented in about 100 session beans, many of them are SFSB using an XPC. We have of course a web UI, but we also have several remote clients which make heavy use

of the business logic implemented in the beans. Our bean methods are fine grained, it is essential for us to allow the remote client to start, commit or rollback transactions on its own, spanning

several calls to different session beans.

This all worked fine for years with JBoss 5.1 and it would be a major regression if this wouldn't work with JBAS7 or WildFly.

Thanks!

[smarlow]

So, how can we proceed?

Do you still want me to test this with EAP 6, too?

I don't think you need to bother trying on EAP 6 also.

As far as how to proceed, I'm not sure yet as we don't want to merge the different extended persistence contexts, instead we need a way to share (at stateful bean instantiation time which is when the context is injected) a lazily initialized extended persistence context that doesn't get fully initialized until the first use.  At least that is what I thinking now.

[smarlow]

I created tracking jira WFLY-2504 for this effort.  I created this jira targeted at the next (WildFly) release, to allow time for some code refactoring and the (default xpc inheritance) configuration changes to be included in the admin console.  We are past the point of making changes like this in the WildFly 8 branch as we are stabilizing the code base.

Just to reflect for a second on what the heck is going on here with the transition from AS5 - AS7/WF 8.  Our AS 5 release correctly implemented EE 5 as described in the specification.  What was later discovered during the AS7 development, was that there was some ambiguity in the specification which was discussed in the above link to the JPA 2.1 expert group mailing list.  From the JPA 2.1 expert list discussion, we came up with two extended persistence context inheritance modes (SHALLOW + DEEP).  The "deep" inheritance mode allows sibling beans to share an extended persistence context even if their parent bean doesn't share the same extended persistence context.  The "shallow" mode does not allow sibling beans to share an extended persistence context if their parent bean doesn't share the same extended persistence context.  The parent bean, is the (local) bean that instantiates the stateful bean (via injection or jndi lookup). 

I need to walk through https://svn.jboss.org/repos/jbossas/projects/ejb3/trunk + https://svn.jboss.org/repos/jbossas/projects/jpa/trunk a bit and make sure my idea for WFLY-2504 will work.

If you have time to experiment some more, do you have a way to see what happens if a user transaction is not started with AS5  and you invoke the two beans?  Will the two stateful beans share the same extended persistence context or not?  I'll look for the answer in the above code but it would be good if you could also check (perhaps printing the EntityManager would be enough).  Might also print the return value from System.identityHashCode(entitymanager).

[ahaumer]

Hi Scott!

I extended my little test application and did some more tests.

My EAR now contains 6 beans:

1. TestSLSB1 - stateless session bean with transactional persistence context "xpctestPU"
2. TestSLSB2 - stateless session bean with transactional persistence context "xpctestPU"
3. TestTPCSFSB1 - stateful session bean with transactional persistence context "xpctestPU"
4. TestTPCSFSB2 - stateful session bean with transactional persistence context "xpctestPU"
5. TestXPCSFSB1 - stateful session bean with extended persistence context "xpctestPU"
6. TestXPCSFSB2 - stateful session bean with extended persistence context "xpctestPU"

All beans derive from the same class AbstractBean which provides one bean method: helloWorld()

This method returns a string with information about the bean, EntityManager, transaction and Hibernate session.

The remote client gets two instances of each bean, calls the helloWorld() method of each one and prints the results to stdout.

It does this twice: First without user transaction (so each method call gets it's own transaction), then inside a single user transaction.

Here are the results with JBAS5:

First the test without user transaction:

Hello testSLSB1a, this is xpctest.TestSLSB1@4e03884e (em=org.jboss.jpa.tx.TransactionScopedEntityManager@4f0ecbfe, identityHashCode=1326369790, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:63 status: ActionStatus.RUNNING >, session=#174171140)
Hello testSLSB1b, this is xpctest.TestSLSB1@1c4c7ecb (em=org.jboss.jpa.tx.TransactionScopedEntityManager@4f0ecbfe, identityHashCode=1326369790, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:67 status: ActionStatus.RUNNING >, session=#572823097)
Hello testSLSB2a, this is xpctest.TestSLSB2@5e4e6d6b (em=org.jboss.jpa.tx.TransactionScopedEntityManager@3fce25b5, identityHashCode=1070474677, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:6b status: ActionStatus.RUNNING >, session=#1810294015)
Hello testSLSB2b, this is xpctest.TestSLSB2@32a00e57 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@3fce25b5, identityHashCode=1070474677, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:6f status: ActionStatus.RUNNING >, session=#1393888979)
Hello testTPCSFSB1a, this is xpctest.TestTPCSFSB1@54739f65 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@453e5e9b, identityHashCode=1161715355, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:73 status: ActionStatus.RUNNING >, session=#1426041570)
Hello testTPCSFSB1b, this is xpctest.TestTPCSFSB1@460f34c0 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@453e5e9b, identityHashCode=1161715355, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:77 status: ActionStatus.RUNNING >, session=#2078163238)
Hello testTPCSFSB2a, this is xpctest.TestTPCSFSB2@3ee430af (em=org.jboss.jpa.tx.TransactionScopedEntityManager@699bf2f1, identityHashCode=1771827953, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:7b status: ActionStatus.RUNNING >, session=#1071210526)
Hello testTPCSFSB2b, this is xpctest.TestTPCSFSB2@32080ca4 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@699bf2f1, identityHashCode=1771827953, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:7f status: ActionStatus.RUNNING >, session=#1979514480)
Hello testXPCSFSB1a, this is xpctest.TestXPCSFSB1@68b1caa8 (em=org.jboss.ejb3.entity.ExtendedEntityManager@7e100578, identityHashCode=2114979192, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:83 status: ActionStatus.RUNNING >, session=#344720025)
Hello testXPCSFSB1b, this is xpctest.TestXPCSFSB1@532902ea (em=org.jboss.ejb3.entity.ExtendedEntityManager@7e100578, identityHashCode=2114979192, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:86 status: ActionStatus.RUNNING >, session=#107421904)
Hello testXPCSFSB2a, this is xpctest.TestXPCSFSB2@4d88a2cb (em=org.jboss.ejb3.entity.ExtendedEntityManager@4eff235d, identityHashCode=1325343581, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:89 status: ActionStatus.RUNNING >, session=#905946208)
Hello testXPCSFSB2b, this is xpctest.TestXPCSFSB2@53a268de (em=org.jboss.ejb3.entity.ExtendedEntityManager@4eff235d, identityHashCode=1325343581, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8c status: ActionStatus.RUNNING >, session=#1318932559)

As you can see, all tests run fine.

There are some things worth to mention, though:

• Without user transaction each method call gets it's own transaction as you can see from the transaction hash code. No surprise here.
• The bean instances are different for each call (even for SLSB), but the EntityManager instance is the same for both instances of the same bean class each. I didn't expect this.
• Without user transaction, the underlying Hibernate Session is different for each method call (even if the EntityManager is the same). This should answer your last question and this is as expected (IMHO).

Now the tests with user transaction started on the remote client:

Hello testSLSB1a, this is xpctest.TestSLSB1@4e03884e (em=org.jboss.jpa.tx.TransactionScopedEntityManager@4f0ecbfe, identityHashCode=1326369790, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testSLSB1b, this is xpctest.TestSLSB1@1c4c7ecb (em=org.jboss.jpa.tx.TransactionScopedEntityManager@4f0ecbfe, identityHashCode=1326369790, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testSLSB2a, this is xpctest.TestSLSB2@5e4e6d6b (em=org.jboss.jpa.tx.TransactionScopedEntityManager@3fce25b5, identityHashCode=1070474677, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testSLSB2b, this is xpctest.TestSLSB2@32a00e57 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@3fce25b5, identityHashCode=1070474677, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testTPCSFSB1a, this is xpctest.TestTPCSFSB1@54739f65 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@453e5e9b, identityHashCode=1161715355, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testTPCSFSB1b, this is xpctest.TestTPCSFSB1@460f34c0 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@453e5e9b, identityHashCode=1161715355, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testTPCSFSB2a, this is xpctest.TestTPCSFSB2@3ee430af (em=org.jboss.jpa.tx.TransactionScopedEntityManager@699bf2f1, identityHashCode=1771827953, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testTPCSFSB2b, this is xpctest.TestTPCSFSB2@32080ca4 (em=org.jboss.jpa.tx.TransactionScopedEntityManager@699bf2f1, identityHashCode=1771827953, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1157344337)
Hello testXPCSFSB1a, this is xpctest.TestXPCSFSB1@68b1caa8 (em=org.jboss.ejb3.entity.ExtendedEntityManager@7e100578, identityHashCode=2114979192, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#344720025)
Hello testXPCSFSB1b, this is xpctest.TestXPCSFSB1@532902ea (em=org.jboss.ejb3.entity.ExtendedEntityManager@7e100578, identityHashCode=2114979192, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#107421904)
Hello testXPCSFSB2a, this is xpctest.TestXPCSFSB2@4d88a2cb (em=org.jboss.ejb3.entity.ExtendedEntityManager@4eff235d, identityHashCode=1325343581, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#905946208)
Hello testXPCSFSB2b, this is xpctest.TestXPCSFSB2@53a268de (em=org.jboss.ejb3.entity.ExtendedEntityManager@4eff235d, identityHashCode=1325343581, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 7f000002:9951:5284db71:8f status: ActionStatus.RUNNING >, session=#1318932559)

Again, there are some interesting things worth to mention:

• With user transaction, the transaction is the same for all method calls. This is as expected.
• With user transaction, the underlying Hibernate Session is the same for all SLSB and transaction-scoped PC SFSB. This is a surprise for me, I didn't expect this.
• With user transaction, the underlying Hibernate Session is different for all SFSB with extended PC. This is as expected (IMHO).

With WildFly 8.0.0.Beta2-SNAPSHOT I changed the client a little to test several situations when running inside a user transaction:

• Situation #1: call to beans with transaction-scoped PC, then call bean with XPC
• Situation #2: call to XPC bean, then call another instance of the same XPC bean
• Situation #3: call to XPC bean, then call instance of another XPC bean

Here are the results:

First the test without user transaction:

Hello testSLSB1a, this is xpctest.TestSLSB1@554f842c (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@576e9075, identityHashCode=1466863733, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:14 status: ActionStatus.RUNNING >, session=#991847412)
Hello testSLSB1b, this is xpctest.TestSLSB1@554f842c (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@576e9075, identityHashCode=1466863733, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:18 status: ActionStatus.RUNNING >, session=#200800321)
Hello testSLSB2a, this is xpctest.TestSLSB2@21cf0884 (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@1f382373, identityHashCode=523772787, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:1b status: ActionStatus.RUNNING >, session=#513762056)
Hello testSLSB2b, this is xpctest.TestSLSB2@21cf0884 (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@1f382373, identityHashCode=523772787, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:1f status: ActionStatus.RUNNING >, session=#1469148164)
Hello testTPCSFSB1a, this is xpctest.TestTPCSFSB1@50f1e31f (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@387631bd, identityHashCode=947270077, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:22 status: ActionStatus.RUNNING >, session=#1471908928)
Hello testTPCSFSB1b, this is xpctest.TestTPCSFSB1@643f700b (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@d51598, identityHashCode=13964696, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:26 status: ActionStatus.RUNNING >, session=#628928149)
Hello testTPCSFSB2a, this is xpctest.TestTPCSFSB2@54d2661d (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@412e256c, identityHashCode=1093543276, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:2a status: ActionStatus.RUNNING >, session=#1016788706)
Hello testTPCSFSB2b, this is xpctest.TestTPCSFSB2@66944e1f (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@129509d6, identityHashCode=311757270, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:2e status: ActionStatus.RUNNING >, session=#1991821857)
Hello testXPCSFSB1a, this is xpctest.TestXPCSFSB1@1bd7615 (em=ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], identityHashCode=1033067927, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:32 status: ActionStatus.RUNNING >, session=#367363094)
Hello testXPCSFSB1b, this is xpctest.TestXPCSFSB1@914d6b (em=ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], identityHashCode=1131523095, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:35 status: ActionStatus.RUNNING >, session=#1540963480)
Hello testXPCSFSB2a, this is xpctest.TestXPCSFSB2@65e936e6 (em=ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], identityHashCode=840133199, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:38 status: ActionStatus.RUNNING >, session=#413696568)
Hello testXPCSFSB2b, this is xpctest.TestXPCSFSB2@46fdc558 (em=ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], identityHashCode=1051146449, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3b status: ActionStatus.RUNNING >, session=#1417888121)

Everything runs fine!

Worth mentioning:

• Each call gets its own transaction and its own session (as expected).
• Calls to SLSB of the same bean class get the same bean instance (which is ok, IMHO, as they come from the pool) and the same EntityManager instance (even though the Hibernate Session is different)

Now the test for situation #1: inside user transaction, first calls to SLSB, then transaction-scoped PC SFSB, then to XPC SFSB:

Hello testSLSB1a, this is xpctest.TestSLSB1@554f842c (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@576e9075, identityHashCode=1466863733, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
Hello testSLSB1b, this is xpctest.TestSLSB1@554f842c (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@576e9075, identityHashCode=1466863733, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
Hello testSLSB2a, this is xpctest.TestSLSB2@21cf0884 (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@1f382373, identityHashCode=523772787, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
Hello testSLSB2b, this is xpctest.TestSLSB2@21cf0884 (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@1f382373, identityHashCode=523772787, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
Hello testTPCSFSB1a, this is xpctest.TestTPCSFSB1@50f1e31f (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@387631bd, identityHashCode=947270077, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
Hello testTPCSFSB1b, this is xpctest.TestTPCSFSB1@643f700b (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@d51598, identityHashCode=13964696, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
Hello testTPCSFSB2a, this is xpctest.TestTPCSFSB2@54d2661d (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@412e256c, identityHashCode=1093543276, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
Hello testTPCSFSB2b, this is xpctest.TestTPCSFSB2@66944e1f (em=org.jboss.as.jpa.container.TransactionScopedEntityManager@129509d6, identityHashCode=311757270, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:3e status: ActionStatus.RUNNING >, session=#213864434)
javax.ejb.EJBTransactionRolledbackException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=xpc-wildfly.ear#xpctestPU, persistence context already in transaction =org.hibernate.jpa.internal.EntityManagerImpl@42abf2ff, extended persistence context =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU].
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
[...]

Caused by: javax.ejb.EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=xpc-wildfly.ear#xpctestPU, persistence context already in transaction =org.hibernate.jpa.internal.EntityManagerImpl@42abf2ff, extended persistence context =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU].
    at org.jboss.as.jpa.container.ExtendedEntityManager.internalAssociateWithJtaTx(ExtendedEntityManager.java:133)
    at org.jboss.as.jpa.container.SFSBCallStack.pushCall(SFSBCallStack.java:151)
    at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:54)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:127)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
[...]

Here we get the exception as soon as we try the first call to the first XPC SFSB.

As with JBAS5 it is interesting to see, that on all calls to SLSB and transaction scoped PC SFSB we get the same Hibernate Session. I didn't expect this.

Now situation #2: first call the first instance of XPC SFSB1, then call the second instance of SFSB1

Hello testXPCSFSB1a, this is xpctest.TestXPCSFSB1@3eed31ae (em=ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], identityHashCode=1180219080, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:48 status: ActionStatus.RUNNING >, session=#1783113868)
javax.ejb.EJBTransactionRolledbackException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=xpc-wildfly.ear#xpctestPU, persistence context already in transaction =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], extended persistence context =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU].
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
[...]

Here we get the exception on the second call.

And finally situation #3: first call the first instance of XPC SFSB1, then call the first instance of SFSB2

Test with user transaction (situation #3)
Hello testXPCSFSB1a, this is xpctest.TestXPCSFSB1@5975dbe1 (em=ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], identityHashCode=1219935913, flushMode=AUTO, tx=TransactionImple < ac, BasicAction: 0:ffff7f000002:-105ad7d6:5284dcfe:4e status: ActionStatus.RUNNING >, session=#1436511882)
javax.ejb.EJBTransactionRolledbackException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=xpc-wildfly.ear#xpctestPU, persistence context already in transaction =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU], extended persistence context =ExtendedEntityManager [xpc-wildfly.ear#xpctestPU].
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
[...]

Again, we get the exception on the second call.

You can find the source code of my test implementation attached as tar archive containing the full Eclipse project structure.

Last, but not least I would like to elaborate on one point you mentioned in your last post: from my (i.e. the remote client) point of view this all is not about persistence context inheritance between session beans! On the remote client I do not expect to get the same persistence context of the same PU when calling methods on different session bean instances. I'm fine with having detached entities to work with and I do not expect lazy loading to work on the remote client. This is something I can deal with on the remote client (and I do since the old days of JEE5).

I just want to be able to control the transaction when I call the beans, even if (and up to now I expect that to be the case) all bean instances use different persistence context instances.

[ahaumer]

Hi!

I just did another test: I ported the test application to Glassfish v4 and let it run.

(as always you can find all the source code as Eclipse project structure in the attachment)

The method calls without user transaction on the client run fine just like with WildFly:

Hello testSLSB1a, this is xpctest.TestSLSB1@394f987b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@18a3d0a2, identityHashCode=413388962, flushMode=AUTO, tx=JavaEETransactionImpl: txId=1 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@7a7ee719, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@21765923])
Hello testSLSB1b, this is xpctest.TestSLSB1@394f987b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@18a3d0a2, identityHashCode=413388962, flushMode=AUTO, tx=JavaEETransactionImpl: txId=2 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@5e831f95, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@728e9fac])
Hello testSLSB2a, this is xpctest.TestSLSB2@50b9d65b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@58a819c4, identityHashCode=1487411652, flushMode=AUTO, tx=JavaEETransactionImpl: txId=3 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@433c055, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@61980e9a])
Hello testSLSB2b, this is xpctest.TestSLSB2@50b9d65b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@58a819c4, identityHashCode=1487411652, flushMode=AUTO, tx=JavaEETransactionImpl: txId=4 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@350972, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@19ff1b79])
Hello testTPCSFSB1a, this is xpctest.TestTPCSFSB1@3ef9a2aa (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@77266732, identityHashCode=1999005490, flushMode=AUTO, tx=JavaEETransactionImpl: txId=5 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@7a4140ba, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@5200b20a])
Hello testTPCSFSB1b, this is xpctest.TestTPCSFSB1@4d655c52 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@39903330, identityHashCode=965751600, flushMode=AUTO, tx=JavaEETransactionImpl: txId=6 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@2a10b1d6, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@2e0b6e2d])
Hello testTPCSFSB2a, this is xpctest.TestTPCSFSB2@3fe35c7e (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@67cd74f6, identityHashCode=1741518070, flushMode=AUTO, tx=JavaEETransactionImpl: txId=7 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@61b9f7b7, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@78364180])
Hello testTPCSFSB2b, this is xpctest.TestTPCSFSB2@1deb46e9 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@417c7a57, identityHashCode=1098676823, flushMode=AUTO, tx=JavaEETransactionImpl: txId=8 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@53440757, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@173e0b76])
Hello testXPCSFSB1a, this is xpctest.TestXPCSFSB1@30164154 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@51b0a76, identityHashCode=85658230, flushMode=AUTO, tx=JavaEETransactionImpl: txId=9 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@324bcb98, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@e2381f4])
Hello testXPCSFSB1b, this is xpctest.TestXPCSFSB1@4729c4ce (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@737d4e2, identityHashCode=121099490, flushMode=AUTO, tx=JavaEETransactionImpl: txId=10 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@62794521, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@7a9ac09])
Hello testXPCSFSB2a, this is xpctest.TestXPCSFSB2@7ef197b6 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@271f6ed6, identityHashCode=656371414, flushMode=AUTO, tx=JavaEETransactionImpl: txId=11 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@a5b7ab, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@7fbd3be1])
Hello testXPCSFSB2b, this is xpctest.TestXPCSFSB2@220564a5 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@10129e16, identityHashCode=269655574, flushMode=AUTO, tx=JavaEETransactionImpl: txId=12 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@3648be98, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@61d908ff])

Things get interesting when I start a user transaction on the remote client!

It works if I first call the beans with extended PC and all other beans afterwards:

Hello testXPCSFSB1a, this is xpctest.TestXPCSFSB1@2b2cbd9e (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@654e637, identityHashCode=106227255, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testXPCSFSB1b, this is xpctest.TestXPCSFSB1@38b40194 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@31d3b8a1, identityHashCode=835958945, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testXPCSFSB2a, this is xpctest.TestXPCSFSB2@41674176 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@61facb85, identityHashCode=1643826053, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testXPCSFSB2b, this is xpctest.TestXPCSFSB2@64b480e5 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@67a6e0a, identityHashCode=108686858, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testSLSB1a, this is xpctest.TestSLSB1@394f987b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@18a3d0a2, identityHashCode=413388962, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testSLSB1b, this is xpctest.TestSLSB1@394f987b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@18a3d0a2, identityHashCode=413388962, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testSLSB2a, this is xpctest.TestSLSB2@50b9d65b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@58a819c4, identityHashCode=1487411652, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testSLSB2b, this is xpctest.TestSLSB2@50b9d65b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@58a819c4, identityHashCode=1487411652, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testTPCSFSB1a, this is xpctest.TestTPCSFSB1@6b76449f (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@219359d7, identityHashCode=563304919, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testTPCSFSB1b, this is xpctest.TestTPCSFSB1@5cf06cd7 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@2c79c6ec, identityHashCode=746178284, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testTPCSFSB2a, this is xpctest.TestTPCSFSB2@401f1125 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@379eb506, identityHashCode=933147910, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])
Hello testTPCSFSB2b, this is xpctest.TestTPCSFSB2@260debd1 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@5bf4f9db, identityHashCode=1542781403, flushMode=AUTO, tx=JavaEETransactionImpl: txId=52 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@d82db019 localTxStatus=0 syncs=[])

As you can see, all method calls run within the same transaction (txId=52)

But If I first call the beans with transactional PC and then call the XPC beans, I get a similar exception as with JBAS7 or WildFly:

Hello testSLSB1a, this is xpctest.TestSLSB1@394f987b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@18a3d0a2, identityHashCode=413388962, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Hello testSLSB1b, this is xpctest.TestSLSB1@394f987b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@18a3d0a2, identityHashCode=413388962, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Hello testSLSB2a, this is xpctest.TestSLSB2@50b9d65b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@58a819c4, identityHashCode=1487411652, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Hello testSLSB2b, this is xpctest.TestSLSB2@50b9d65b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@58a819c4, identityHashCode=1487411652, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Hello testTPCSFSB1a, this is xpctest.TestTPCSFSB1@4df89be3 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@7cc27c12, identityHashCode=2093120530, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Hello testTPCSFSB1b, this is xpctest.TestTPCSFSB1@32333d4 (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@7c1fa4e7, identityHashCode=2082448615, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Hello testTPCSFSB2a, this is xpctest.TestTPCSFSB2@3518194b (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@4124a628, identityHashCode=1092920872, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Hello testTPCSFSB2b, this is xpctest.TestTPCSFSB2@7ceeedaa (em=com.sun.enterprise.container.common.impl.EntityManagerWrapper@2a3573fa, identityHashCode=708146170, flushMode=AUTO, tx=JavaEETransactionImpl: txId=66 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@9bbb0230 localTxStatus=0 syncs=[])
Exception in thread "main" javax.ejb.EJBException: There is an active transactional persistence context for the same EntityManagerFactory as the current stateful session bean's extended persistence context
    at com.sun.ejb.containers.StatefulSessionContainer.validateEMForClientTx(StatefulSessionContainer.java:2769)
    at com.sun.ejb.containers.EJBContainerTransactionManager.useClientTx(EJBContainerTransactionManager.java:360)
    at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:251)
    at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4433)
    at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1921)
    at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:204)
    at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
    at com.sun.proxy.$Proxy198.helloWorld(Unknown Source)
    at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
    at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
    at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
    at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
    at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
    at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
    at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
    at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
    at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
    at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
    at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
    at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
    at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)

Are remote clients second class citizens in the JEE world now?

I begin to get the feeling that I will have much fun with this in the near future... :-(

[smarlow]

Thank you for the results and effort.  I will have more questions but am busy with something else at the moment, so will respond in a few days (or so).

[smarlow]

Are your stateful session beans clustered?  In AS 7 + WildFly 8, all of the beans that share the same extended persistence context should fail over to the same node.  I'm curious if you are clustering these SFSBs that share the same XPC?

Scott

[ahaumer]

No, no clustering.

I did all tests with AS7 and Wildfly with a pristine, out-of-the-box AS distribution with the standalone configuration.

The only changes in standalone.xml are increased logging settings.