Lampson and Lomet’s Paper: A New Presumed Commit Optimization for Two Phase Commit Doug Cha COEN 317 – SCU Spring 05

About the authors Butler Lampson Currently at MSFT Currently at MSFT Formerly at Xerox PARC, DEC research, and a professor at MIT and Berkeley Formerly at Xerox PARC, DEC research, and a professor at MIT and Berkeley ACM Turing Award in 1992 ACM Turing Award in 1992 David Lomet Also at MSFT, formerly at DEC research Also at MSFT, formerly at DEC research Key work on database systems Key work on database systems One of the inventors of the transaction concpet One of the inventors of the transaction concpet ACM Fellow ACM Fellow

Outline Review of 2PC More on 2PC / Optimizations Presumed Nothing Presumed Nothing Presumed Abort Presumed Abort Presumed Commit Presumed Commit Recovery requirements The new PrC protocol Summary

Review of 2PC Distributed Atomic Commit problem (DC9 p2) How to get all members of a group to commit/abort together? How to get all members of a group to commit/abort together? Two Phase Commit, Gray 1987 (DC9 p3): First phase is the voting phase First phase is the voting phase Coordinator sends all participants (cohorts) a vote request (PREPARE) All participants (cohorts) respond COMMIT-VOTE or ABORT-VOTE Second phase, coordinator decides commit or abort: if any participant voted ABORT, then decision must be abort. Otherwise, commit. Second phase, coordinator decides commit or abort: if any participant voted ABORT, then decision must be abort. Otherwise, commit. Coordinator sends all participants decision (COMMIT or ABORT) Participants (who have been waiting for decision) commit or abort as instructed and ACK.

2 Phase Commit PREPARE COMMIT-VOTE COMMIT > Coordinator Cohort make vote execute commit ACK Additional Detail – A protocol database at the coordinator stores transaction states and cohort votes. This is used for error recovery.

2PC Variations Presumed Nothing (PrN) Presumed Abort (PrA) Presumed Commit (PrC) Variations deal with how to handle recovery and vary on how recovery data is logged.

Presumed Nothing (PrN) PREPARE COMMIT or ABORT-VOTE COMMIT or ABORT > Coordinator Cohort make vote execute commit ACK Record ACK Forced record 1 forced write, 1 lazy write, 2 messages to cohort > Remove record

PrN Failure Recovery PREPARE COMMIT-VOTE Coordinator Cohort make vote In PrN nothing is recorded until a COMMIT is sent, so coordinator crash results in ABORT. timeout STATUS? crash no record ABORT

PrA Optimization PREPARE ABORT-VOTE ABORT Coordinator Cohort make vote No record On an ABORT, there are no log records and no ACK. This works because we “presume an abort” if no record exists! crash recovery STATUS? no record ABORT

Presumed Commit (PrC) - COMMIT PREPARE COMMIT-VOTE COMMIT > Coordinator Cohort make vote Forced remove record 2 forced write, 2 messages to cohort Cohort doesn’t need to send ACK Forced record crash recovery STATUS? no record COMMIT

Presumed Commit (PrC) - ABORT Coordinator Cohort PREPARE ABORT-VOTE ABORT > make vote execute abort remove record ACK Forced record ACK only needed on ABORTs

Comparison For Now 2PC Variant CoordinatorCohort PrN 2 log records 1 forced log 2 messages to Cohort 2 log records 2 forced log 2 messages to Coordinator PrA 2 log records 1 forced log 2 messages to Cohort 2 log records 2 forced log 2 messages to Coordinator PrC 2 log records 2 forced log 2 messages to Cohort 2 log records 1 forced log 1 messages to Coordinator

Improving PrC Messaging is low already, try to reduce forced log writes. In PrC a forced write happens at PREPARE In PrC a forced write happens at PREPARE Any transactions with a PREPARE, but no transaction end are aborted Non existence of a transaction record assumes commit To remove the forced PREPARE write, we need to: To remove the forced PREPARE write, we need to: Find another way to identify transactions that may have started before the crash but did not finish Keep these transaction records around so we know to abort them (since we are still presuming commits)

Improving PrC Instead of recording trans init, record timestamps: tid l –lowest possible time of an undocumented transaction tid l –lowest possible time of an undocumented transaction tid h –most recent undocumented transaction tid h –most recent undocumented transaction tid sta – most recent record of a transaction tid sta – most recent record of a transaction So we have: REC = { tid | tid l < tid < tid h } = recent transactions REC = { tid | tid l < tid < tid h } = recent transactions COM = commited and stable transactions COM = commited and stable transactions IN = REC – COM = transactions maybe active during crash IN = REC – COM = transactions maybe active during crash On recovery: Cohorts asking status of a transaction assume commit unless the record exists in the IN set Cohorts asking status of a transaction assume commit unless the record exists in the IN set The IN set must be stored forever! (But data size is small) The IN set must be stored forever! (But data size is small) Transaction Log tid l tid h tid sta Window of Active/Undocumented Transactions (REC) Commited or Aborted Transactions Not used space time

The New PrC Protocol ABORT PREPARE ABORT-VOTE ABORT Coordinator make vote increase tid l value past this trans, so IN set does not include this anymore ACK > abort IN range of tids contains this transaction tid l < tid < tid h

The New PrC Protocol COMMIT PREPARE COMMIT-VOTE COMMIT Coordinator make vote No trans record in IN so commit ACK abort recovery / crash STATUS? COMMIT > Move tid l past this IN range of tids contains this transaction tid l < tid < tid h

The New PrC Protocol ABORT/CRASH PREPARE ABORT-VOTE ABORT Coordinator make vote Trans is still in IN set, so we send abort ACK abort crash recovery STATUS? ABORT IN range of tids contains this transaction

Analysis of New PrC Protocol We reduce the # of forced writes but require permanent storage of IN records 2PC Variant CoordinatorCohort PrC 2 log records 2 forced log 2 messages to Cohort 2 log records 1 forced log 1 messages to Coordinator New PrC 1 log records 1 forced log 2 messages to Cohort 2 log records 1 forced log 1 messages to Coordinator

Summary Two-Phase Commit Presumed Nothing Presumed Nothing Presumed Abort Presumed Abort Presumed Commit Presumed Commit Requirements for logging/recovery Requirements for logging/recovery New Presumed Commit New Presumed Commit

References A New Presumed Commit Optimization for Two Phase Commit – Lampson and Lomet, Distributed Systems Concepts and Design – Coulouris, Dollimore, Kindberg Santa Clara Univ, COEN 317 class notes – Holliday