• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Carey Brown
  • Stephan van Hulst
  • Tim Holloway
  • Peter Rooke
  • Himai Minh
  • Piet Souris
  • Mikalai Zaikin

Message-driven bean acknowledgment.

Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

Paresh Vernekar
    Bookmark Topic Watch Topic
  • New Topic