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

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!



Page history last edited by PBworks 16 years, 12 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.