A good friend of mine (ElJaime) posed a question around XA transactions (2 phased commits) vs Idempotency, a great topic so I thought I’d steal it for my blog

Idempotency is an old (mathematical) matrix term that simply says if I multiply a matrix by itself I’ll get the same matrix. Computing re-defines it as an action that if executed repeatedly will produce the same result as if executed once.

“The common pattern alternative to XA/DTC is idempotent receiver (that is, you do not have to coordinate completion of transactions against different resources if you can invoke the transactions on the resources time and again with the same results).

A few questions for the group:
* What are best practices and gotchas in idempotency?
* When are XA transactions truly necessary?”

My response:
What’s better than having a way out? Not needing one. But conceptually are XAs and idempotency really that different? You’re in essence shifting responsibilty from the container to the engineer

I think idempotency is well suited to SOA type situations: The shoeshine guy will clean your shoes again if you ask him, whether they’re clean or not. The point is it’s a deterministic situation which is nice, I know I’ll get clean shoes but it’s lazy in terms of knowing the current state. This works well when coordinating between web services. I’ll look after my data just keep ploughing ahead. As an engineer idempotency gives me a warm feeling inside. Of course it’s important to ID my shoes or I might get the wrong pair back!

Another gotcha obviously is that the programmer will get lazy and never really know the state of the data (or worse; repeatedly generate failures). You assume that because you got so far in a business process that the data is in a certain state, which it may/not be. An alternative is always to execute a compensating transaction; walk in the mud and start over?

The biggest problem I see with idempotency and I could be wrong is that you still need some sort of over-arching state management.
If you’re
1) Activating an account on system A, then
2) signalling system B to begin billing that account
if step 2 fails and fails and fails you’re account’s up but you’re not billing!

Conceptually I think 2pcs put more of an emphasis during design/implementation on ensuring the correctness of the data at each step in the business process. However, in today’s world of SOA and loose coupling it’s getting harder to make a case for XAs or 2PCs, primarily for timing reasons. Queues vs Web Services vs RDBMS will all have different latencies so even if your 2PC runs flawlessly, you’re not guaranteed consistent state and isn’t that the whole point?

The Two Phased Commit is also a great line to throw out at parties.