[rabbitmq-discuss] is anybody using tx?

Thu Jun 30 15:26:02 BST 2011

I've only read part of the thread, but we are making use of
transactions for all of our publishing. We haven't switched to
'confirms' because it's a feature were weren't aware of and it would
need to be thoroughly integrated into our stack.

For us, transactions allow both high throughput and message delivery
reliability. Before transactions, we'd be pushing messages through a
channel and if there was an error, the channel would be closed with
some number of messages lost on that channel. Worse, "frames in
flight" would cause RabbitMQ to close the connection entirely because
it would receive frames on a channel after closing it.

To ensure throughput, we used a pooling scheme that's now abstracted
into haigha's ChannelPool.

We're not overly concerned about compliance with strict adherence to
the AMQP spec as we intend to use RabbitMQ for a long time to come,
but it is beneficial for us to stay within spec to ensure that both
the broker and client are coded to a similar standard.

-Aaron

On Mon, Jun 27, 2011 at 11:02 AM, Matthias Radestock
<matthias at rabbitmq.com> wrote:
> What use, if any, are RabbitMQ users finding for AMQP's tx class?
>
> The predominant application of tx we have seen in the past is as a means for
> the client to ensure that the server has accepted responsibility for a
> published message (or, conversely, be told of any failure to do so).
> Publisher confirms, which we introduced in 2.3.0, handle this much better. I
> suppose there might be still be users that haven't switched from 'tx' to
> 'confirm'. If so I'd like to know what is holding you back.
>
> What else are people using tx for with RabbitMQ? And what aspects of tx
> semantics are you relying on? (Note, for example, that the tx specified in
> AMQP 0-9-1 is very limited. For example, atomicity is not guaranteed for
> transactions affecting more than one queue.)
>
> Our current thinking is that tx, as it stands, is of very limited utility
> and that we are probably better off without it - it adds significant code
> complexity, slows down implementation of new features and is generally
> curtailing the evolution of RabbitMQ.
>
>
> Regards,
>
> Matthias.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

-- 
Aaron Westendorf
Senior Software Engineer
Agora Games
359 Broadway
Troy, NY 12180
Phone: 518.268.1000
aaron at agoragames.com
www.agoragames.com