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

Gordon Sim wrote:

<blockquote cite="mid:496211C9.9040504@redhat.com" type="cite">

  <pre wrap="">Alexis Richardson wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap="">RabbitMQ provides a correct implementation of the TX class which

enables work to be grouped.  It is the TX class to which Gordon refers

in his email below.  The problem is that the definition of TX is open

to *some* interpretation in edge cases, and is implemented slightly

differently by the various brokers.  When we discussed the differences

in the working group we agreed that it would be more useful to clarify

how each 'correct' interpretation actually works for pre 1.0 specs,

pending AMQP 1.0.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

I referred to comments made about the atomicity guarantee in the 

RabbitMQ during discussions on clarifying the text of the TX class.

My view has always been that the TX class implied atomicity (and the 

original author confirmed that was his intention), but the text of the 

0-9 (and earlier) spec(s) did not make that explicit.

  </pre>

</blockquote>

<br>

It would be good to note that the word 'transaction' implies ACID - <i>Atomicity,

Consistency, Isolation, Durability<br>

<br>

Needing to specify ACID with the word transaction is redundant in my

view.<br>

<br>

<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Transaction_processing">http://en.wikipedia.org/wiki/Transaction_processing</a><br>

<br>

I would go as far as to say, a transaction that is not Atomic is NOT a

transaction, but rather just some or other variation<br>

of an acknowledgment pattern and should not be called a transaction.<br>

<br>

Carl.<br>

<br>

<br>

</i>

</body>

</html>