5 ms·

ATMs are a great example of a system that really don't need a two phase commit protocol. You have an account, it has a balance, and the transaction is a subtrac

ATMs are a great example of a system that really don't need a two phase commit protocol. You have an account, it has a balance, and the transaction is a subtraction from the balance. A dumb ATM would read the balance value, subtract, and issue a "set balance to $$$" transaction. A good ATM would check the balance, ensure theres enough money (or overdraft..) for the request, and record a "subtract $40" transaction. If this message gets delayed, oh well, the customer might end up with a negative balance - sucks for the bank if the customer decides to go into hiding - but as the customer typically can't control the delay - it's hard for them to abuse this feature. (I only consider delay here, as I'm sure ATMs make multiple durable copies of their transaction log - making all but the biggest disaster unlikely to prevent them from being able to retrieve the TX's eventually) On the other hand, most systems are nowhere near this "simple". What happens when 3 Github users all simultaneously edit the same Github organisations description? You can't just add/subtract each of the changes. One change has to win, or in other words, two changes need to be rejected. I feel like the authors text really only covers the ATM style use case, a valid use case, but one that's already reasonable to solve without 2 phase commits. Once you are willing to accept & able to handle check+set race conditions, things get much easier :)

falcor84 8y ago
I don't quite understand the issue with the GitHub use case. If the operation is just "set name to X", then multiple such operations are trivially serializable and the latest one will win. All prior changes are accepted, performed and immediately overwritten, there's no need for any coordination at all. Or am I missing something?
- kiallmacinnes 8y ago
  Yes, In my opinion, you're missing the user experience aspect. Two of the three should be rejected - not overridden. - so the users get the feedback they expect, rather than reloading the page and seeing something totally different. And yes - It's a trivial example, one defined by UX - but there are many examples of needing to reject a transaction that can't simply be overridden (or replayed later like simple addition/subtraction) - and I don't see how the authors proposal replaces two phase commit in something like that.
  - amelius 8y ago
    But assume the system updates changes infinitely fast. Then assume user A makes a change, and only after 30 microseconds user B makes a change. Will user A now be confused because their change is overwritten by user B? If so, then the problem has nothing to do with the aforementioned situation and the UX should probably show: "user B is also editing this field" or something like that. The point is: it does not matter if the system is slow and rejects changes; because the effect to the user will be the same as in the "infinitely fast" case.
    - zzzcpan 8y ago
      I think it's fair to assume no collaborative text editing would actually occur on that field at all. And so last write wins is perfectly acceptable strategy here and no coordination is actually necessary, and neither is necessary to inform the user about conflicting edits. For UX it might be useful to observe own edit, but that can be done completely locally with data only eventually propagating farther. Incidentally this is also pretty much the only way to make the edit reliably synchronized with the remote system, because users don't have perfectly reliable computers, perfectly reliable internet connections and won't wait long for anything.
    - LukeShu 8y ago
      How fast the system makes updates has nothing to do with it. Premise: The current state is "foo". Alice would like to change the state to "bar". Bob would like to change the state to "baz". Alice and Bob are friendly (non-antagonistic) coworkers. Naive sequence: 1. Alice: READ STATE => foo 2. Bob: READ STATE => foo 3. Alice: SET STATE=bar 4. Bob: SET STATE=baz <-- this is where the "confusing"/"wrong" thing happened. Bob did not expect to overwrite his coworker's work. The solution is that instead of a naive "set", to use "test-and-set" operation.
      - polynomial 8y ago
        Bob may or may not be concerned with what the state is/was, and more concerned with what state the system needs to converge on. I take your point, although the assumption is that Bob wants to set state=baz IFF (if and only if) state==foo. However he may simply need the state to be baz, regardless what the previous state was.
- syrrim 8y ago
  You could record a character wise diff of each name update, and apply all the diffs in succession. GP is saying not to do that, and instead to only apply one of the name changes and ignore the rest -just as you've described.
statusgraph 8y 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.
- kiallmacinnes 8y ago
  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 :)
  - lugg 8y ago
    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.
    - viraptor 8y ago
      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.
      - lugg 8y ago
        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-7028-1.pdf https://link.springer.com/content/pdf/10.1007/s10619-008-702...
neffy 8y ago
Actually... no it´s not. The underlying technology is a medieval single error correction/detection process called double entry book keeping. So the operation is some variant of [credit cash, debit account] or [debit deposit account1, credit deposit account2] tldr: banking is more interesting than generally realised.
sobellian 8y ago
If I were implementing the ATM example, I'd do something similar to Auth/Capture where the balance check places a hold on the funds until an eventual capture / reversal. Of course, that is basically 2PC in spirit.
wut42 8y ago
>If this message gets delayed, oh well, the customer might end up with a negative balance - sucks for the bank if the customer decides to go into hiding - but as the customer typically can't control the delay - it's hard for them to abuse this feature. Nope! When I'm just at +40€ on my account, I can get three or four times (in separate transactions) this amount in a short window of time. I have no authorized overdraft, but end-up with -80€.
- kiallmacinnes 8y ago
  The bank still controls this delay, and deems it acceptable - you can't extend the delay, and use the extension to withdraw thousands and thousands of extra euros! Chances are, the costs of a real-time system, vs the cost of unauthorised overdrafts isn't a tradeoff worth fixing for them. (That and, at least here in Ireland, the banks can and do charge for unauthorised overdrafts - which is ridiculous IMHO, but that's a separate thing)

falcor84 8y ago

I don't quite understand the issue with the GitHub use case. If the operation is just "set name to X", then multiple such operations are trivially serializable and the latest one will win. All prior changes are accepted, performed and immediately overwritten, there's no need for any coordination at all. Or am I missing something?

kiallmacinnes 8y ago
Yes, In my opinion, you're missing the user experience aspect. Two of the three should be rejected - not overridden. - so the users get the feedback they expect, rather than reloading the page and seeing something totally different. And yes - It's a trivial example, one defined by UX - but there are many examples of needing to reject a transaction that can't simply be overridden (or replayed later like simple addition/subtraction) - and I don't see how the authors proposal replaces two phase commit in something like that.
- amelius 8y ago
  But assume the system updates changes infinitely fast. Then assume user A makes a change, and only after 30 microseconds user B makes a change. Will user A now be confused because their change is overwritten by user B? If so, then the problem has nothing to do with the aforementioned situation and the UX should probably show: "user B is also editing this field" or something like that. The point is: it does not matter if the system is slow and rejects changes; because the effect to the user will be the same as in the "infinitely fast" case.
  - zzzcpan 8y ago
    I think it's fair to assume no collaborative text editing would actually occur on that field at all. And so last write wins is perfectly acceptable strategy here and no coordination is actually necessary, and neither is necessary to inform the user about conflicting edits. For UX it might be useful to observe own edit, but that can be done completely locally with data only eventually propagating farther. Incidentally this is also pretty much the only way to make the edit reliably synchronized with the remote system, because users don't have perfectly reliable computers, perfectly reliable internet connections and won't wait long for anything.
  - LukeShu 8y ago
    How fast the system makes updates has nothing to do with it. Premise: The current state is "foo". Alice would like to change the state to "bar". Bob would like to change the state to "baz". Alice and Bob are friendly (non-antagonistic) coworkers. Naive sequence: 1. Alice: READ STATE => foo 2. Bob: READ STATE => foo 3. Alice: SET STATE=bar 4. Bob: SET STATE=baz <-- this is where the "confusing"/"wrong" thing happened. Bob did not expect to overwrite his coworker's work. The solution is that instead of a naive "set", to use "test-and-set" operation.
    - polynomial 8y ago
      Bob may or may not be concerned with what the state is/was, and more concerned with what state the system needs to converge on. I take your point, although the assumption is that Bob wants to set state=baz IFF (if and only if) state==foo. However he may simply need the state to be baz, regardless what the previous state was.
syrrim 8y ago
You could record a character wise diff of each name update, and apply all the diffs in succession. GP is saying not to do that, and instead to only apply one of the name changes and ignore the rest -just as you've described.

statusgraph 8y 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.

kiallmacinnes 8y ago
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 :)
- lugg 8y ago
  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.
  - viraptor 8y ago
    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.
    - lugg 8y ago
      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-7028-1.pdf https://link.springer.com/content/pdf/10.1007/s10619-008-702...

neffy 8y ago

Actually... no it´s not. The underlying technology is a medieval single error correction/detection process called double entry book keeping. So the operation is some variant of [credit cash, debit account] or [debit deposit account1, credit deposit account2] tldr: banking is more interesting than generally realised.

sobellian 8y ago

If I were implementing the ATM example, I'd do something similar to Auth/Capture where the balance check places a hold on the funds until an eventual capture / reversal. Of course, that is basically 2PC in spirit.

wut42 8y ago

>If this message gets delayed, oh well, the customer might end up with a negative balance - sucks for the bank if the customer decides to go into hiding - but as the customer typically can't control the delay - it's hard for them to abuse this feature. Nope! When I'm just at +40€ on my account, I can get three or four times (in separate transactions) this amount in a short window of time. I have no authorized overdraft, but end-up with -80€.

kiallmacinnes 8y ago
The bank still controls this delay, and deems it acceptable - you can't extend the delay, and use the extension to withdraw thousands and thousands of extra euros! Chances are, the costs of a real-time system, vs the cost of unauthorised overdrafts isn't a tradeoff worth fixing for them. (That and, at least here in Ireland, the banks can and do charge for unauthorised overdrafts - which is ridiculous IMHO, but that's a separate thing)