[rabbitmq-discuss] Fwd: question on the faq

[Tim Coote]

I've now read a bit of the specs :-)
amqp defines tx classes (which are not transactional in the sense of  
XOpen's XA specification) and dtx, which are.  I don't understand, at  
the moment, what tx really means in the context of a message passing  
system, but I suspect that it's something to do with some sort of  
'transactional' model with a message server (or whatever I call the  
agent that my application interacts with that is its interface to the  
messaging system): I can send messages to the message server with  
transactional semantics, but there's no downstream semantics. I'm not  
very clear on how this is a useful piece of functionality as I cannot  
see what guarantees I get for it.

iirc, MQSeries had similar semantics about 'guaranteed delivery',  
which are not much use, either, as you still have to put in place  
checks for message receipt by the end point.

Could the two types of 'transaction'  causing some confusion?

Tim

On 5 Jan 2009, at 15:37, Gordon Sim wrote:

>
> Matthias Radestock wrote:
>> Gordon Sim wrote:
>>> 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.
>>> (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).
>> Not quite. Firstly, if queues are active entities, which they are  
>> in RabbitMQ, then they can, in principle, die due to some failure.
>
> I would view that as a bug.
>
>> 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).
>
> Would RabbitMQ abort any open transaction involving the queue in  
> that case?
>
>

Tim Coote
tim at coote.org
vincit veritas