[rabbitmq-discuss] Fwd: question on the faq
tim+rabbitmq.com at coote.org
Tue Jan 6 12:37:48 GMT 2009
On 6 Jan 2009, at 11:51, Alexis Richardson wrote:
> Tim, many thanks.
> Also, Gordon and Carl, thanks for your thoughts which really helped by
> forcing us to clarify stuff.
> I am going to re-paste Matthias' last comment which is relevant:
> "Finally, it's worth reiterating that RabbitMQ *does* guarantee
> atomicity in the cases required by the 0-9-1 spec, namely "where all
> publish or ack requests affect a single queue.""
I'm sure that RabbitMQ implements the spec. I come more from the angle
of getting the spec right. I want my customers to be able to avoid any
> On Tue, Jan 6, 2009 at 10:42 AM, Tim Coote <tim
> +rabbitmq.com at coote.org> wrote:
>> I'm getting the sense that as far as AMQP is concerned, the word
>> Transaction is not helpful
> I must admit that I tend to share this view. However, it is also
> clear from people's comments, notably Gordon and Carl, that other
> views are defensible. In other words - this is all good fuel for
> making a better 1.0 spec. In AMQP 1.0 we anticipate a much more
> rigorous definition of transactionality and 'resource' including DTX
> and idempotency. Implementations supporting that will also have finer
> grained means for coping with TX anomalies such as corner 'failure
I'd recommend using a different term, eg 'transactional control', or
(from my pov) inventing an entirely new word/phrase so that customers
are aware that they need to look into what the phrase means.
> And AMQP needs to play nicely with JMS which has its own
> resource-centric behaviours.
> TX for example can be related to the concept of a JMS local
> transaction (unless I have misunderstood this). Moving data from one
> queue to another, on one broker, is not dissimilar to the TX use that
> Gordon described.
unsure. it's quite possible that the AMQP terminology started in the
JMS world. iirc, the j2ee OTS service is the relevant transactional
service. I don't know how the language and computational models
percolated into JMS.
> Of course the MAIN aim of AMQP is to simplify integration (and lower
> cost) by simplifying cross-platform messaging. So it has to be
> cognitively obvious as well as semantically so. Thanks for making us
> talk through this in the TX case.
It seems to make a good job of this, from what I can see.
> Please could you elaborate on the 'reconciliation of state'
Whenever there is distributed persistence, there's a risk of the
different views of the world getting out of sync. So you need some
periodic checks that the views are consistent. If you have ACID
semantics on the information, this happens infrequently and can be at
quite a high level (eg testing that the history of the past or future
plans have consistent totals for, say, number of bookings, or volume
of material to be exchanged.) If I have no ACID transactions, I ought
to validate the result of each update/request for resources from each
service explicitly. As I've got no distinct time boundaries around
when the (application level) transaction completed, I need to build
that functionality, too. This balloons the application design, build,
and maintenance costs.
>> Using what I'd call the normal semantics of a transaction, I'd define
>> a unit of work that booked all of my components of my holiday in one
>> block and I'd know whether everything were ok or not. It also makes
>> very obvious that I need to think about the legal contracts that I'm
>> 'committing' to so that I can form suitable compensating
>> Using the AQMP definition, all I know is that the booking requests
>> were delivered, and possibly not even that they'd all been delivered.
> Right and here one stumbles across the difference between TX, DTX and
> idempotent delivery. But - correct me if I am wrong - wouldn't
> Gordon's use case help with this?
I'm not sure. I didn't get the gory details. But I don't think that it
addresses the issue as I think it's concerned with the control
mechanisms, not the content. The point about my example is that I
have guarantees on the ACID characteristics of the components of the
holiday: not just that the booking forms were delivered to the
companies concerned, but that they were accepted and correctly
processed. By extension, I suppose that this could form the basis of a
legal contract, but I'm no lawyer.
btw, an idempotent operation to me means that I can apply it one or
many times and I get the same result (eg x=3, vs x+=1). Is this
another 'broadened' definition :-)
> Possibly so.. Do you use XA a lot then?
Yes. But as a reference specification/basis for application
architectures/enterprise standards. Or as a pointer on how things
should have been done on a post mortem ;-) I do less of this type of
work these days, but was heavily involved last century. :-)
More information about the rabbitmq-discuss