I'll try to go straight to the point: one of the valid EJB 2.0 scenarios for distributed transaction management is so-called "client-managed", where the transaction is started and committed by the client as follows
UserTransaction ut = initialContext.lookup("UserTransaction");
// invoke EJB business methods
It's the apps responsibility to enlist any resource who wants to participate in the distributed transaction because, according to the specification , the transactional context is transmitted from the client to the application server.
Let's consider further the client being Tomcat running in a separate VM.
As far as I know, Tomcat uses it's own jndi repository.
Here is the point though: when I make the lookup from the client(tomcat), I create the initial context with jboss parameters. So far everything is fine, and a valid ut is returned from JBoss. When I call the ut.begin(), the ClientUserTransaction class (implementation of the UserTransaction) tries to get a reference to the UserTransactionSessionFactory with the following code:
factory = (UserTransactionSessionFactory)new InitialContext().lookup("UserTransactionSessionFactory");
Again, we are in the client and the no-argument constructor for InitialContext will look for the Tomcat initial context instead of the JBoss context, where UserTransactionSessionFactory is actually located. Hence the error saying "the object does not belong to this context"
Maybe everything comes from my misunderstanding of the EJB specifications and the transactional context cannot be transmitted between Tomcat and JBoss if they run in separate VMs. In this case, why the UserTransactionSessionFactory is registered under global namespace in JBoss's JNDI?
If this is indeed an unexpected behaviour, would there be any chance to specify a property file in order to access the desired repository? (I tried to copy the jndi.properties with jboss parameters under the tomcat classpath without success)
I am using Tomcat 4 and JBoss 3.0 alpha with JDK 1.4 beta 3