From the HFEJB book, it said that Container will acknowledge the JMS server when it receive the message so JMS server can remove that message from the Queue. And if the message processing fail, the Container will tell the JMS server so the JMS server can put that message back into the queue.
But later the book say, if we use CMT in MDB and then receive a bad message that can never commit, the JMS server will keep sending that message to the Container. And results in a suggestion that should use BMT to avoid this issue.
How can the JSM server keep sending that message if it is removed from the Queue in the first place.
Sound like, the Container will sent JMS server the acknowledge only after the message processing success. The message will be remain in the Queue until the JMS server get the acknowledge from the Container, and it make sense with this assumption.
HI, In this case, the container will send the message to MDB and acknowledge the same to JMS provider.The JMS provider will remove the message from the queue.In case of a transaction rollback, the message will be placed back on the queue.As a result, the container will then again pick up the message and send it to an MDB, may or may not be the same instance.If the transaction rollsback again, the same process is repeated. This is something known as 'poison message'. It depends on the JMS provider to provide some kind of configuration option to prevent this scenario.
Hope this clears your doubt
Regards, Paresh Vernekar
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com