The jdbc2 transaction has nothing to do with the
client transaction. You do not need an XA DB for jdbc2
You do need an XA DB if you want to do two phase rollback
correctly with JMS.
Under what circumstances are messages lost from the queue?
We have seen messages being lost under the following circumstances:
The application recieves (MDB) a message which it tries to process. If the applciation fails to process the message it starts looping.
We stop the server fix the problem causing exception and restart the server only to find that the message is no longer on the queue.
Unfortunately we have not managed to replicate this in a very predictable manner i.e. in most of the cases the message is still on the queue and gets processed.
I have ensured that we dont have a DLQ set up for that MDB.
Is this in an XA transaction where two-phase is required?
e.g. You access the database in the same transaction?
There was a bug in the rollback that didn't set the redelivered
flag if your MDB continues to rollback you get a loop.
The max redelivered is never looked at because the redelivered
flag is not set.
I think this was fixed around 3.2.2RC1 it is certainly fixed in 3.2.2RC3
This shouldn't cause the message to be lost. It should
spot the transaction didn't complete during recovery and put
the message back in the queue.