As long as you keep your transaction chains in each container operating as you would expect them to operate, if the JBoss chain encounters a problem completing it's atomic task it rolls back it's transaction and throws the exception. The WebLogic client receives the exception and throws an internal exception to roll back the transaction locally. However, this simple scheme assumes that the WebLogic transaction has completed all its work before the JBoss call, as you wouldn't be able to rollback the JBoss call, if after the call has returned, you discover that the WebLogic transaction itself cannot complete.
Hope that makes sense and have read your intent correctly.
thanks for the reply. this looks like a poor man's solution with the absence of a transaction manager coordinating the distributed transcations? i guess i am looking for a "real" solution by somehow enlisting the jboss's transaction to weblogic's transaction manager.
I don't think it is that poor. It is the simplest means of chaining transactions and it works in the manner that is prescribed by the J2EE spec (interfacing through the container walls between an EJB and a client).
If you want a single controlling transaction manager, then you have three choices:
1) Buy Tivoli
2) Build your own transaction integrator to couple the transaction managers between the two systems, build-in the signalling and synchronisation and get it to work between JVMs (clustering two different container implementations)
3) Have the transactions in a unified container/cluster
Solutions 1 and 2 are going to cost, they are going to be complex, most likely you will take a substantial performance hit and the audit logs will be complex to trace. But if that is what you need, then that is what you need.
You are going to be balancing cost, complexity, failure modes and ultimately risk to project. That will determine what your solution will look like.
I should emphasise, as I said at the start that this is the simplest EJB-compliant solution. You also have available to you programmatic control from the client EJB for transaction demarcation through the use of JTA and if you are using stateful session beans, SessionSynchronization.