Re: Asynchronous acknowledgements - are they correct?

>
> 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.
>
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://www.nabble.com/Asynchronous-acknowledgements---are-they-correct--tp17277656s2354p17280899.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>