• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Whenever you search in PBworks or on the Web, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, Slack, and browsed web pages. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.



Page history last edited by PBworks 15 years, 11 months ago


  • 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

Comments (0)

You don't have permission to comment on this page.