I'm not sure about JBoss, but the Arjuna+JBoss product ( http://www.arjuna.com/products/jboss) addresses this requirement.
The free 30 evaluation version of the product comes with a demo app that involves a client application accessing EJBs in two JBoss instances within the same global transaction.
The infrastructure takes care of propagating the transaction context between client and servers and ensuring that any xa resources which may be needed e.g. the two databases used for EJB state, are enrolled in the same global transaction. You get reliable distributed 2PC and automatic crash recovery without any significant programming effort.
could you elaborate more on how your problem is solved with local interfaces.
Well, the problem that I pose requires 2+ seperate VMs. To have these VMs communicate to each other, a remote interface must be exposed. This creates a Transaction Management issue that Arjuna + JBoss handles(via XATransactions and such). Somewhere, there must be a Omniscient Transaction Manager handling all possible combinations of Resources and which transaction is using which resources(via XID and XAResource).
Forcing Local Interfaces means that Server "A" can never call Server "B", it can only call on resources that Server "A" provides. If the resources on Server "B" were exposed on Server "A" (either remote or local), Server "A" would be complete. The Jboss TM can handle the 1 VM problem.
It can work with both remote/local on the same server. But if the decision is to cluster/HA the previous 1 VM environment and the environment is designed to use remote interface... You'll have the scenario I mentioned before. You'll need a more complex TM to handle the Transaction state of this complex system.
Correct me if I'm wrong.
> From my experience, I would see the TM of server A start a transaction with some XID then call Server "B". Server "B" would then start a different XID and do its work. Is this the correct assumption?
You're right. This is what Jboss's transaction manager does. It does not propagate transactional context. As server "B" receives a request without transactional context, it starts a new transaction, completely independent of server "A"'s one.
> If so, is there any way to pass the XID to Server "B" so that its committable resources share the same transaction?
Yes, but not using the default TM as it is. You would have to modify it or use a third party implementation (Arjuna, for example, as mentioned in the other reply).
> How are commits handled if Server "A" is the source of the commit call? Can the commit be expected to propagate to Server "B"? What happens if Server "B" uses resources that Server "A" does not?
Well, as there will be two distinct transactions, each one will do 2PC with its own resources. And no commits will be propagated.
I hope I've helped. Feel free to contact me if you have any questions...
Just curious. Why do you need distributed transactions? Even if JBoss supported distributed transaction propagation, IT SHOULD BE AVOIDED AT ALL COST. DTP is extremely slow no matter whose implementation you use, you will also have a VERY hard time debugging concurrency issues.
Sorry, but I'm a bit amazed. If you think that distributed transaction
propagation should be avoided at all cost, why Jboss supports it by way of TransactionPropagationContextFactory and TransactionPropagationContextImporter interfaces?.
I think, though it is really costly there are situations in which it will be useful. such as when you are working with an existing server and you can't deploy your application in the same server.
I suppose you can use web services and ws-transaction to control the whole process, but I think it will be slowly.
Just curious, what solution do you suggest when have to work in a situation like that described by Ivan?.
I agree with you in that TPC is costly. By example, I'm working in its implementation for the integration of Jboss and Jotm and It will be necessary to propagate the transaction context back to the caller JVM for the registration of global coordinator.