Distributed transactions
Last updated
Was this helpful?
Last updated
Was this helpful?
https://docs.google.com/spreadsheets/d/1Sw0T4R6-Bb3orF0abwkmiZRBbCioevH1jvyjnw7aqhs/edit?usp=sharing
The nodes are in blocked status during the execution.
The coordinator could be the single point of failure in the entire process.
If any single failure happens among participants, all participants need to rollback transaction. And this could be high performance cost.
This introduces another phase before prepare/commit phase to guarantee that the "Cons 3" in two phase commit get resolved.
However, this seldomly gets used in practice because the benefits are limited.
Each of three phases corresponds to a local transaction.
Try: Prepare transaction but not commit. Insert data.
Confirm: Corresponds to "commit phase" in two phase commit.
Cancel: Corresponds to "rollback phase" in two phase commit.
Typically it won't fail in Try Phase. And it will fail only in Confirm phase.
TCC is an eventual consistency model.
Compensation is more accurate than rollback in saga context because
Rollback applies in uncommitted transaction
Compensation applies in committed transaction
In saga, compensation is a better fit because it reverse committed local transactions.
AT transaction applies when you operate on multiple databases concurrently.
When sharding middlware begins transactions on sharded DB, it has two options:
At "Begin", start transactions on all DB shards.
When executing a certain SQL statement, decide which shards to start transactions
Retry on failure
Human intervention
Asynchronously fix inconsistency
