3 ms·

That's the way Megastore does it too. Optional 2PC for transactions that span entity groups. So what's wrong with 2PC?

by Xorlev 11y ago

takeda 11y ago
If you have a distributed system and need to create a transaction across multiple nodes 2PC has some shortcomings[1], the 3PC is addressing this. [1] https://en.wikipedia.org/wiki/Three-phase_commit_protocol#Motivation https://en.wikipedia.org/wiki/Three-phase_commit_protocol#Mo...
- frazerclement 11y ago
  Note that the 2PC in Ndb is not quite the same as that used for the normal '2PC is blocking' arguments : 1. The transaction coordinator (TC) role is automatically taken over in case of the failure of the coordinator during commit. The new coordinator uses the surviving participants' states to quickly decide on Commit or Abort so that locked resources are released. 2. As the participants are part of an integrated system, failure of both the coordinator and e.g. the only participant to be aware of the commit decision can be handled correctly. In this case the transaction is quickly aborted by the new coordinator and on recovery the old participant will 'undo' its local committed-state before rejoining the cluster. 3. Participants' local commit decisions are not coupled directly to lock release / visibility of those decisions. Locks are released only when the participant-failure-durability of the commit decision is assured (e.g. all replicas have committed). 4. Ndb has a third phase (The complete phase) which releases locks on replicas. This is not the same as the algorithm referred to as three phase commit, so we don't call it three phase commit. Also, the third Complete phase is not part of the critical commit path - the commit acknowledgement is sent to the application prior to the start of the third phase, so it does not affect the user's experienced commit latency. Not all '2PC' implementations are created equal.

That's the way Megastore does it too. Optional 2PC for transactions that span entity groups. So what's wrong with 2PC?

by Xorlev 11y ago

That's the way Megastore does it too. Optional 2PC for transactions that span entity groups. So what's wrong with 2PC?

If you have a distributed system and need to create a transaction across multiple nodes 2PC has some shortcomings[1], the 3PC is addressing this. [1] https://en.wikipedia.org/wiki/Three-phase_commit_protocol#Motivation https://en.wikipedia.org/wiki/Three-phase_commit_protocol#Mo...

frazerclement 11y ago
Note that the 2PC in Ndb is not quite the same as that used for the normal '2PC is blocking' arguments : 1. The transaction coordinator (TC) role is automatically taken over in case of the failure of the coordinator during commit. The new coordinator uses the surviving participants' states to quickly decide on Commit or Abort so that locked resources are released. 2. As the participants are part of an integrated system, failure of both the coordinator and e.g. the only participant to be aware of the commit decision can be handled correctly. In this case the transaction is quickly aborted by the new coordinator and on recovery the old participant will 'undo' its local committed-state before rejoining the cluster. 3. Participants' local commit decisions are not coupled directly to lock release / visibility of those decisions. Locks are released only when the participant-failure-durability of the commit decision is assured (e.g. all replicas have committed). 4. Ndb has a third phase (The complete phase) which releases locks on replicas. This is not the same as the algorithm referred to as three phase commit, so we don't call it three phase commit. Also, the third Complete phase is not part of the critical commit path - the commit acknowledgement is sent to the application prior to the start of the third phase, so it does not affect the user's experienced commit latency. Not all '2PC' implementations are created equal.