<br><div class="gmail_quote">On Mon, Jun 27, 2011 at 4:02 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
What use, if any, are RabbitMQ users finding for AMQP's tx class?<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
<br>
Regards,<br>
<br>
Matthias.<br>
<br></blockquote><div><br>I do not have high throughput requirements. But I do have reasonably strong "never lose a message" requirements. For this I use durable queues and persitant messages. And I use tx to tell the producer that the message has been persisted.<br>
<br>I haven't yet looked at confirm.<br><br>Robby<br><br></div></div>