Paper

• 2P model: coordinator, subordinates
• commit, no failure:
  • user -> coordinator: comit transaction
  • coordinator -> subordinates: PREPARE
  • subordinatre -> force write to disk: PREPARE
  • subordinate -> coordinator: YES VOTE
  • or subordinate -> coordinator: NO VOTE (acts like a veto)
  • all yes: coordinator -> force write disk: COMMIT
  • coordinator -> subordinates: COMMIT
  • subordinates -> force disk: COMMIT
  • subordinates -> coordinator: ACK
  • any no: coordinator -> subordinates who said YES: ABORT
  • subordinates -> force disk: ABORT
  • subordinates -> coordinator: ACK
• coordinator can "forget" about transaction after all ACKs recieved
• 2P and failures:
  • recovery process reads logs, listens to recovery messages
  • PREPARED: periodically try to contact coordinator to find result of transaction
  • if coordinator is waiting for a vote, notices site failure -> ABORT
  • if subordinate is about to send vote, notices coordinator failure -> ABORT
  • if coordnator recieves a recovery question, send "remembered" COMMIT|ABORT, (no info = ABORT)
• hierarchical 2P: root and leaves act as 2P, middle layers act as aggrigators. also force-writes commit messages
• note that because the no info stat is abort, we can drop all tracking for aborted transactions
• note that read-only, or partially read-only transactions don't need to log on some leaf nodes: leaf nodes can send a READ VOTE
• the coordinator can track who is read-only, and only send commit messages to those that VOTE YES
• presumed abort (PA): no info = abort with shortcuts (no ACKs needed)
• presumed commit (PC): no info = commit
• problem: this creates a problem: if the coordinator or midlevel node crashes after PREPARE but before collecting votes (some may have voted no)
• solution: force write who it will send prepares to so it can send abort
• differences from PA:
  • force writes COLLECTING which include subordinates, moves into collecting state
  • force write only ABORT
  • requires ACKS for ABORT only
  • write an END after ABORT only
  • if it notices a subordinate failutre when aborting, hand transaction over to recovery process
  • read only transactions require writting a commit record
  • subordinates only ACK  and force-write ABORTs
• system could hint that transaction is read-only, for which PA would be better
• transaction manager code (TM) operate on root and midlevel nodes, database manager code (DBM) runs on leafs
• both use checkpoints to bound recovery time
• one deadlock detector and each site (DD)
• only current deadlock information read: read only once
• detects local and potential global dealock cylces (PGDC)
• choose local victim so as to minimize complexity in choosing and implementing other methods
• since a transaction may reaquire locks during the ABORT phase (why?) only one abort process per node
•