• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Paul Clapham
  • Devaka Cooray
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Liutauras Vilda
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Piet Souris
Bartenders:
  • salvin francis
  • Carey Brown
  • Frits Walraven

Message-driven bean acknowledgment.

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

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.

please correct if I went wrong.


Thanks.
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
You can thank my dental hygienist for my untimely aliveness. So tiny:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
    Bookmark Topic Watch Topic
  • New Topic