3 ms·

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

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?

arethuza 3mo ago
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 3mo ago
  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_starbucks.html https://www.enterpriseintegrationpatterns.com/ramblings/18_s...
mrkeen 3mo ago
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 3mo ago
  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 3mo ago
    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.
pragmatic 3mo ago
[dead]

arethuza 3mo ago

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 3mo ago
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_starbucks.html https://www.enterpriseintegrationpatterns.com/ramblings/18_s...

mrkeen 3mo ago

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 3mo ago
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 3mo ago
  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.

pragmatic 3mo ago

[dead]