<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Matthias Radestock wrote:
<blockquote cite="mid:49621F7C.8090502@lshift.net" type="cite">
<pre wrap="">Gordon Sim wrote:
</pre>
<blockquote type="cite">
<pre wrap="">A general atomicity guarantee is more basic than that though and would
in my view be valuable even if it only applied where queues involved in
that transaction were not deleted during the life of the transaction.
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">(Note the only way a queue should disappear due to failure is if the
broker restarts and the queue was not durable, in which case any open
transactions would be aborted).
</pre>
</blockquote>
<pre wrap=""><!---->
Not quite. Firstly, if queues are active entities, which they are in
RabbitMQ, then they can, in principle, die due to some failure.
Secondly, in a clustered RabbitMQ broker each queue resides on a
specific node. In such a set up a transaction may take place on a
connection+channel against one particular node but involve queues
residing on other nodes. Those queue can disappear due to node failure
or network connectivity disruption without the transacted
connection+channel being dropped (since the node which holds the
connection is still alive and well).</pre>
</blockquote>
<br>
Sound like a bug. <br>
<br>
If something is transactional then it should be ACID, so if a node
fails and is restarted it <br>
should be recover-ed from the transaction log. Once a client has
successfully committed <br>
the txn, the broker weather single instance or cluster should be in a
consistent state<br>
or be able to be recover-ed to the consistent state to trans-send the
failure.<br>
<br>
Carl.<br>
</body>
</html>