|
|
|
|
|
|
by layer8
219 days ago
|
|
|
I disagree. The definition of a two-phase commit protocol is that you have a number of participants in a transaction, and the first phase consists of asking each participant if they can commit, and if or when all participants affirm positively, then the second phase consists of telling all participants to perform the commit. Let’s not dilute well-established terms. The procedure in the article is not a two-phase commit, because changes are committed to the system of reference regardless of whether the subsequent commit to the system of record succeeds or not. In addition, half of the rule in the article is about the ordering of reads, which two-phase commit isn’t concerned about at all. |
|
|
Intent: Begin the durable execution (i.e. resonate.run)
Prepare: Write to the system of reference -- safe to fail here.
Commit: Write to the system of record -- the commit boundary.
Ack/Recovery: checkpointing + idempotent replays.
Abort/Compensation: panic or operator intervention.
Ordering operations has always been a thing you should do. And they’re treating this as a distributed system to simulate an ACID transaction. For example, if you ever do locks of multiple things, the order you take the locks has to be the same across the entire system so that you never deadlock. If your database is taking locks, then order matters there too. They rediscovered what us in the distributed systems world have always known and fairly well-documented: ordering is how you simulate time and prevent paradoxes.