Hacker News new | ask | show | jobs
by statusgraph 2694 days ago
Two-phase commit deals with network failure, not change semantics. The message itself (whether "BALANCE=40" or "SUBTRACT 40") isn't something that matters to 2pc.
1 comments

You're absolutely correct, but change semantics changes how you deal with network failure, there not entirely independent - and I'm aware my example is likely too simple, but typing a better one on a phone is hard :)
You're actually both wrong. 2 phase commit is used for all kinds of things. It doesn't always require a network to be involved.

And you were wrong because your example is not a good example of something not needing 2 phase commit, it was in fact an example of a 2 phase commit. That over-drafting you mentioned, that is deferred reconciliation.

That is not the 2PC I know. From Wikipedia: "It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction". ATMs don't do 2PC. They can't about a money transaction which already happened.

Also wiki: "two-phase commit protocol (2PC) is a type of atomic commitment protocol". That's different from deferred conflict resolution from event log.

The two phases in the ATM scenario would be,

Phase 1 ATM Request to withdraw funds secures a lock

Phase 2 Gets the all clear, writes the new balance to the ledger, distributes funds.

Anything trying to modify the ledger at that same time should be blocked for the short time it takes to process the transaction.

This is how these systems work.

The reconciliation is what happens when you can't do 2pc or when it fails.

Re it being a network protocol, no, its been around d since the dark ages.

https://link.springer.com/content/pdf/10.1007/s10619-008-702...

> The two phases in the ATM scenario would be,

> Phase 1 ATM Request to withdraw funds secures a lock

> Phase 2 Gets the all clear, writes the new balance to the ledger, distributes funds.

> Anything trying to modify the ledger at that same time should be blocked for the short time it takes to process the transaction.

So you're saying 2PC is basically just "acquire a lock... do two things... release lock"?

In essence yes.

Once you get into implementation detail you have to deal with a heap of failure modes which is what the article is complaining about in the premise.

What I don't really understand is how their solution isn't basically just sharding (in some form.)