Unanimous 2PC: Fault-tolerant Distributed Transactions Can be Fast and Simple
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNdvHOrCl5q5Qd1cCrAQAJ8NgTL2yBaSkWiQe40S5po6RFrOguGArDDd0yonA3NVlCl3H3LXkBLyacTWAdoxGOhK0ZLMGaeEhVCSjnhIUpnxvD-NoCR1rb3orqkjvEUCbJi2jhVqOeOIk3wWgUwZa8wzJHyi9EH1OGDAwOjtzPAzZuaXtFxuTmuoVCUkU/w400-h265/Screenshot%202024-07-03%20at%2011.16.25%E2%80%AFAM.png)
This paper (PAPOC'24) is a cute paper. It isn't practical or very novel, but I think it is a good thought-provoking paper. It did bring together the work/ideas around transaction commit for me. It also has TLA+ specs in the appendix, which could be helpful to you in your modeling adventures. I don't like the paper's introduction and motivation sections, so I will explain these my way. The problem with 2PC 2PC is a commit protocol. A coordinator (transaction manager, TM) consistently decides based on participants (resource managers, RMs) feedback to commit or abort. If one RM sees/applies a commit, all RMs should eventually apply commit. If one RM sees/applies an abort, all RMs should eventually apply abort. Below figure shows 2PC in action. (If you are looking for a deeper dive to 2PC, read this .) There are three different transactions going on here. All transactions access two RMs X and Y. T1, the blue transaction is coordinated by C1, and this ends up committing.