[rabbitmq-discuss] Fwd: question on the faq

[Alexis Richardson]

Tim,

On Mon, Jan 5, 2009 at 4:14 PM, Tim Coote <tim+rabbitmq.com at coote.org> wrote:
> I've now read a bit of the specs :-)

Yay!

Which one(s) did you read?


> amqp defines tx classes (which are not transactional in the sense of XOpen's
> XA specification) and dtx, which are.

0-10 has a DTX definition.


> I don't understand, at the moment,
> what tx really means in the context of a message passing system,

TX provides the ability to group messages in a message flow or
'stream', for managing eg visibility.



>  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.

It gives you a way to acknowledge an action or set of actions.



> 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.

Yes and such behaviour is not TX or DTX ;-)



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

Verily...

alexis




> 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
>
>
>
>