Transactions in Enterprise Server/JMS Adapter

I have a problem with the way Enterprise Server/JMS Adapter handles transactions. In an integration component, I want to send a message to an application through a message queue and then read the reply that arrives on another queue.
What happens is that the sending of the request is delayed until the (local) transaction commits, that is till the end of the script. So I don’t get a reply from the system (actually after the time out period I get an empty reply). Further more next time I invoke this integration component I get the reply to the request I submitted the time before!?!

Any ideas ?
Thanks
Andrea

You probably want to use two integrations. The first integration would end with posting the message to the queue. The second one would trigger off a message being available on the second queue. The tricky part would be handling the case when no message came back from the application. Someone else may have a good way to handle that.

Thanks for your answer. In my specific case, splitting the integration in two poses a problem. In my integration I have a document. I take some fields from the document and send them (via JMS)to the application. I get an answer, add it to the document and publish the whole thing.
Now if I split the integration in two, how do I send the original document to the second integration ?

The easy answer is to pass the whole document on the JMS queue to your application, and have it return the whole thing. But the easy answer for the integration side may not be easy for your application, plus it might mean performance problems.

It may be better to set up a seperate storage area for your original document. Put it in a database if you have one available, write it to a file, whatever makes sense in your environment. Then you can re-read the original data in your second integration. You can pass a key in your JMS message that lets you get the original document back, or perhaps there’s a code on the JMS message that will serve that purpose already (like a trackId on a webMethods document).

None of this is the ideal solution, so if someone else has a better idea on how to avoid the issue of JMS request/reply, please jump in. But this should work, despite being horribly inelegant.

If I’m understanding you correctly, I think your first message has to be a one way message. If you use a point-to-point message, set the AcknowledgeMode to CLIENT_ACKNOWLEDGE. That way, the receiving application can ack receipt of the message explicitly, as soon as it is picked up (as opposed AUTO_ACKNOWLEDGE, which waits until it is finished processing). You could also try using a Topic instead of a Queue and do a publish, using persistence if message loss is an issue.

After sending the first message you should then be free to connect to the second queue to wait for the reply.

Hope that helps.