J2EE / JMS Controlling transaction in util.jar

Question

Hi all experts!
I've a delicate problem where I want to handle transactions transparently for EJBs in my util jar. I�m familiar with the other alternatives (MDBs etc) and using them in other parts of the solution but they can�t be used here (need a synchronous request-reply).
The description is a bit long but please bare with me, hopefully it is clear and understandable.
Summary:
Why can't I use a UserTransaction in a utility.jar when called from a EJB using container managed transaction.
Senario:
transport_util.jar:
Transport utility package contains no EJBs, just simple java classes (to make usage / deployment more simple for the users of the util.jar).
The EJBs use an ApplicationFacade in the transport_util.jar (not a EJB just a java class) providing a high level communication API for JMS transport, encapsuling JMS specific code, and providing the simple transport primitives:
- void send(Object data) : writing fire and forget messages to JMS Queue
- Object requestReply(Object data) : sending a request message and waiting
synchronously for a reply message. Not pretty when using messaging but
necessary in this solution.
AnyEJB.jar:
The �client� using the transport primitives in transport_util.jar. The transport_util.jar is included in the EAR application as a utility.jar. The EJBs can use either Container (CMT) or Bean Managed Transactions (BMT). The transport_util.jar shouldn�t set any limitations.
Problem:
The problem arise when a �client� EJB under CMT calls the requestReply function in the API. The message is written to the JMS Queue by the transport_util before it starts to listen for a reply, on a in Queue, which will be returned to the caller. The request message is nerver delivered to the recipient who there for won�t produce a reply.
Why? Because it is written to the JMS Queue inside a transaction (implicit from the calling EJB) which has not been committed (and shouldn�t from the clients perspective) before the API starts to listen for the reply. No delivery until commit! The transactional parameter isn�t valid when inside a application server
My idea of a solution:
Start a new UserTransaction, putTx, inside the requestReply function to halt the callers transaction (J2EE doesn�t support nested trans) and use it around the put operation. After a successful put the putTx could be committed, without affecting the callers transaction, which would lead to the message being sent to the recipient and finally a reply could arrive. Only one big problem.:
I get a naming exception when trying to lookup the UserTransaction through JNDI if the calling EJB use CMT but not if it uses BMT. Why? Is there a workaround?
InitialContext ctxt = new InitialContext();
UserTransaction putTx = ctxt.lookup(�java:comp/UserTransaction�)
putTx.begin();
// Put message on queue
putTx.commit();
// Try read reply from queue
Infrastructure:
- IBM WebSpehere Application Server 5
- IBM WebSpehere MQ 5.3
- Java 1.3
Exception excerpt:
Error occurred while handling transaction
[2003-09-04 17:06:47:479 CEST] 7f8389dc SystemOut O javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:".
[2003-09-04 17:06:47:479 CEST] 7f8389dc SystemOut O      at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1003)
[2003-09-04 17:06:47:479 CEST] 7f8389dc SystemOut O      at com.ibm.ws.naming.urlbase.UrlContext.lookup(UrlContext.java:1211)
[2003-09-04 17:06:47:479 CEST] 7f8389dc SystemOut O      at com.ibm.ws.naming.urlbase.UrlContext.lookup(UrlContext.java:1203)
[2003-09-04 17:06:47:479 CEST] 7f8389dc SystemOut O      at com.ibm.ws.naming.urlbase.UrlContext.lookup(UrlContext.java:1257)
[2003-09-04 17:06:47:479 CEST] 7f8389dc SystemOut O      at javax.naming.InitialContext.lookup(InitialContext.java:359)
/Best regards
Jesper

Answer 1

If anyone else have the same problem....
After a great tip from a colleague a good solution if found!
By getting hold of the TransactionManger from the ApplicationServer it is possible to suspend an ongoing transaction, start a new one and commit it and restart the suspended transaction again.
Looking up the TransactionManger differs a lot from AppServer to AppServer. To find out how it is done on yours take a peak in the code of any of bigger persistence frameworks (I looked at Hibernate).
So in pseudo code:
// Error checks not in code to keep it short
// Look up the TransactionManager
TransactionManager mgrTx = //
// Suspend callers Tx
Transaction callerTx = mgrTx.suspend();
// Start new transaction for the work to be performed
// outside the callers transaction
mgrTx.begin();
// Perform transacted work .....
// Commit
mgrTx.commit();
// Reassign the callers transaction to the thread and activate if
mgrTx.resume(callerTx);/J