Hello Rob - thanks for your quick reply.
rajdavies wrote:
Your summary is correct. You can always use transactions - but even
then there is a window when the server could crash whilst the client
is waiting for a response from the commit.
Yes that is true, but there is an important difference. If a commit returns successfully then you know for sure that the transaction has been committed and any acks in that transaction have been processed.
However if a call to acknowledge() returns successfully with activemq you *do not know* that the acks have been processed.
Admittedly a call to commit() might not return successfully and the transaction still might have been committed but that is a different story.
rajdavies wrote:
Ultimately, messaging is
asynchronous - and the JMS spec states that applications should cater
for the case where redeliveries can occur.
The JMS spec also states that AUTO_ACKNOWLEDGE should give "at most once" delivery semantics but with active mq it is actually giving "dups_ok" delivery semantics (since you can get duplicates). Which I would read to be in contravention to the spec.
You'll find that other messaging systems send acnowledgements sychronously in order to be JMS spec compliant. (They have to). Of course this gives a performance penalty since sending async is always going to be quicker.
I guess it's a tradeoff between reliability and correctness versus performance, and ActivemQ has chosen the performance route.
