22.7. Commit and abort in a distributed system
Let us assume in the case of 2PL and TSO that the transaction manager at the coordinating node has received a request to commit a transaction. We have to ensure:
| Atomicity | Either all nodes commit the changes or none do, and any other transaction perceives the changes made at every node or those at none. |
| Isolation | The effects of the transaction are not made visible until all nodes have made an irrevocable decision to commit or abort. |
We have set up the conditions that no scheduler will refuse to commit the transaction on correctness grounds. In 2PL and TSO we have avoided this possibility by only allowing serializable invocations to take place. For these pessimistic methods there are two remaining issues ...
Get Operating Systems: Concurrent and Distributed Software Design now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
