[rabbitmq-discuss] When is persister.log.previous made?

[Matthias Radestock]

Tsuraan,

tsuraan wrote:
>> As an aside, why are you using transactions on the consuming side? I
>> have yet to come across a use case where that is genuinely required.
> 
> Our consumers are almost always also producers, so we do the message
> ack and the creation of new messages in a transaction.  I'm not sure
> that it's necessary; I'm used to databases, where I tend to do
> everything in a transaction to ensure that everything is consistent
> when I'm done, but our messaging stuff is designed to handle multiple
> copies of the same message, so it's probably a bit overkill to also
> use transactions.
> 
> I seem to remember that I had some problem when I was first looking at
> rabbit that I could publish a stream of messages in non-transactional
> mode, and not all the messages would be delivered (or enqueued).  I
> think I may have been doing something stupid like exiting my program
> without closing my channel, but moving to transactional mode fixed the
> problem, and I think I've been a bit religious about transactions
> since then.

Transactions are currently the only way for a client to get an
acknowledgment from the broker that sent messages have not only made it
to the broker (a normal connection/channel.close, or indeed any other
synchronous AMQP operation, is sufficient for that) but also will
survive a broker restart (if they were marked as persistent).

So use of tx mode on the sending side is quite common.

Use of tx mode on the receiving side, for acks, is much less common,
since the worst thing that can happen if an ack gets lost is that the
message will get delivered again. That can happen in other situations
anyway, e.g. client or connection failure, so apps need to be able to
cope with it already.

If your producers are also senders, and you want the aforementioned
guarantees on sending, I would recommend using two channels - one in tx
mode for sending and one on non-tx mode for receiving/ack'ing.


Regard,

Matthias.