[dcminter]

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?

[mrkeen]

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?

[dcminter]

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.

[pragmatic]

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.

[arethuza]

Yeah I once saw a system designed about 2000 or so that pulled messages from an MQ queue and updated a database all within a single transaction managed by COM+. To be honest the distributed transaction side of it seemed more bother than it was worth...

[dcminter]

Yeah, for a lot of systems it really is more trouble than it's worth - I remember enjoying this article when it came out: https://www.enterpriseintegrationpatterns.com/ramblings/18_s...