← Back to context

Comment by dcminter

4 days ago

Is there a reason why two-phase commit can't work with a DB and a message queue? DB2 and MQ Series used to support this (though they called it "XA" transactions and you had to compile support into the drivers which felt a bit sketchy - late 90s I think). Should I have been suspicious of this?

I have the starting state:

  DB={}    Q={}

I would like to either remain in the starting state, or enter a new state:

  DB={Bob paid $15}  Q={Bob paid $15}

But this is Two Generals, which is impossible.

If you invoke 2PC, you want the states to progress thus:

  DB={locked}        Q={locked}

  DB={locked;        Q={locked;
      Bob paid $15}     Bob paid $15}

  DB={locked;        Q={locked;
      Bob paid $15;     Bob paid $15;
      unlocked}         unlocked}

A strictly harder problem, right?

  • Ah, you're assuming distributed, which I wasn't. We are not at home to partition tolerance :)

    Makes sense in the context of the original post though.

    • But you are assuming distributed transactions as soon as you have two systems participating in the transaction.

      It's a recipe for deadlocks and even live locks.

      That's a reason industry moved away from this. Bc when it works it's magic. But when the problems start it's pure hell.