Transaction Management in JMS adapter

Question

Hi,
I am creating a BPEL process for inserting data in a JMS queue (for producing message on queue) with transaction management, and came across the property "isTransacted", can anyone please help me with the functionality of this property, and how to handle transactions with JMS Queue.
Thanks.

Answer 1

First of all the JMS specification does not define the behavior for multiple clients accessing a queue. Having said that, most vendors do offer this. Since it is not defined in the specification mileage can vary from provider to provider. However, most vendors do the obvious/intuitive thing.
When a client receives a message from a queue it is not available to anyone else until the final disposition of that message can be determined. Acknowledge and commit permanently remove the message from the queue. Recover and rollback put the message back in the queue. The death of the client results in a recover or rollback. When a message goes back to the queue, it is made available to all clients who are waiting (possibly even the same client (except in the case of the dead client)).
With respect to your questions, the intuitive behaviors are:
1) message goes back and someone else has a chance to get it
2) If you have a transacted session then the acknowledge is simply ignored, and since you didn't call commit, the message is still considered outstanding (and no one else can get it). If the session is not transacted then the acknowledge causes the message to be permanently removed from the destination (and no one else can get it).
3) if the session is transacted then the commit permanently removes the message from the destination (and no one else can get it). if the session is not transacted then the commit must throw an exception and since you didn't call acknowledge, the message is still considered outstanding (and no one else can get it).
Client2 could only receive the same message if client1 rolledback or recovered the message (which should occur if client1 dies).
_sjz.