[rabbitmq-discuss] Any pre-tx_commit validation possible on a channel?

[David Wragg]

Hi Paul,

Paul McGuire <ptmcg at austin.rr.com> writes:
> I realize that a 100% airtight solution is not possible, but is there
> any way before calling tx_commit to anticipate at least some simple
> failures in sending messages that have been buffered up in a
> transaction?  I am trying to merge AMQP messaging with XA two-phase
> commit.
>
> In XA, I can send the messages (by calling tx_commit) at voting time,
> which would rollback any db changes if the message send fails (at XA
> voting time, any failure causes all other participants to rollback).
> But if I send messages at voting time, consumers of the message see a
> pre-commit view of the database, which is not really what I want.
>
> If I send the message/call tx_commit at XA finish time, then consumers
> will see the post-commit database view, but a failed message send will
> not rollback the database.  (I do still get the benefit of database
> failures causing the message transaction to abort with this approach.)
>
> Is there any channel or message-publishing validation I can do at XA
> voting time that might anticipate a message publishing failure?

No, I'm afraid there is no way to do this.

AMQP (0-9-1) transactions in general are not intended to support
distributed transactions (there is the whole issue of transactions being
scoped to channels, the lack of support for transaction identifiers,
etc.)

It's also questionable whether it's a good idea to combine messaging and
distributed transactions (a significant use of messaging is exactly to
avoid the need for distributed transactions and the problems of
two-phase commit, by providing a robust means for systems to be loosely
coupled).

If you have to integrate AMQP and systems using XA, then I would suggest
using a database to mediate between the messaging system and the
distributed transactions, with some adapters to tie the things together.
For example, on the consuming side, an adapter would convert an incoming
message into a record in the database, commit this in a local
transaction, and ack the message; it would then initiate the distributed
transaction, involving the database but not the messaging system, to act
on that record.  The producing side is similar, though you might need to
use triggers of some kind to avoid polling.

David

-- 
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware