[rabbitmq-discuss] Persistence and Transactions

[Tim Watson]

Hi CJ

On 29 Dec 2012, at 23:26, CJ <rmqjava1a at yahoo.com> wrote:

> Thank you this is very helpful.
> 
> I am writing 2 separate applications.  One sending transactional messages,
> and another receiving transactional messages.  I understand your point about
> the 2 transactions are separate and do not directly affect one another.  My
> purpose for writing the producer and consumer this way is to make the
> applications as robust as possible to retain all messages.
> 

That makes perfect sense.

> In your last post you wrote:
> 
> 
>> For most users where the producer and consumer are decoupled, producer
>> confirms are a better 
>> choice than transactions, although they offer different semantics.
> 
> Why are producer confirms better.  Is this better and will this retain
> messages in the most secure manner possible.
> 

They're as reliable as transactions but offer far superior performance.

> Also, what exactly does a producer confirm entail.  Is this simply an
> auto-ACK ?
> 
> 

No not an auto-ack. Confirms are a RabbitMQ extension to AMQP. When confirms are enabled on a channel, the broker will reply with confirm-ok when it has 'taken full responsibility' for a message. If the queue is durable and the messages are marked as persistent, the broker will only reply once the messages are safely on disk an the file system has been fsynced. You can't really get safer than that.

> 
> --
> View this message in context: http://rabbitmq.1065348.n5.nabble.com/Persistence-and-Transactions-tp24204p24250.html
> Sent from the RabbitMQ mailing list archive at Nabble.com.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss