2011/6/28 Matthias Radestock <span dir="ltr">&lt;<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>&gt;</span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Surely there must be more than four people using tx though. Don&#39;t be shy! Speak up!</blockquote></div><br>Matthias,<br clear="all"><br><div>I have been using RabbitMQ since Jan 2009 or so and still do not use transactions, however, I have one use case that is much easier to</div>

<div>implement with transactions.</div><div><br></div><div>Imagine a fairly large (a few terabytes) collection of documents that are clustered. Clustering can happen around different attributes, lets use date as example.</div>

<div>Application that does clustering is an AMQP consumer. Because of the nature of clustering by date, it needs to process N documents at once</div><div>(so again, batching), and only then acknowledge RabbitMQ and possibly other apps.</div>

<div><br></div><div>Prefetching plus message acknowledgements kinda let me build something like this, however, it will require some extra care on app developer&#39;s side.</div><div>Note that if consumer app would use RDBMS, there is always a possibility of doing a rollback there and at least not having inconsistent/incorrect (w.r.t clustering) data,</div>

<div>but graph databases today typically do not offer transactions and RDBMSes aren&#39;t very good at graph walking.</div><div><br></div><div>I hope this counts as useful feedback.</div><div>-- <br>MK<br><br><a href="http://github.com/michaelklishin" target="_blank">http://github.com/michaelklishin</a><br>

<a href="http://twitter.com/michaelklishin" target="_blank">http://twitter.com/michaelklishin</a><br><br>
</div>