Transaction Management in the R* Distributed Database Management System

C. Mohan, B. Lindsay, and R. Obermarck
IBM Almaden Research Center
Scribe by: Zuyu Zhang

One-line Summary

Overview/Main Points

• Goals for 2PC
  • Guaranteed atomicity (all or nothing) for multi-site updates
  • Ability to “ forget ” transaction outcome quickly
    • Ask coordinator (by only looking at locks, cannot know the result of xact.)
    • Do not have to maintain the large in-memory data structures maintained by the coordinator, whenever the coordinator “ knows ” that if any participants asks it about the xact, with no knowledge of the xact it will give the correct answer.
    • Only store info that will be asked.
  • Minimize overheads of log writes & message traffic by reducing # of both force-writes (consider the coordinator crashes without affecting the correctness) and writes (consider impacts on efficiency but not correctness), and unnecessary messages sent.
  • Optimize performance for normal cases
    • Subordinates hold long time locks in the 2PL scenario between sending vote messages and receiving xact outcome messages.
  • Take advantages of read-only xacts
    • But during the commit protocol, the coordinator cannot ignore a “ read-only ” subordinate, because the coordinator does not know ahead of time which subordinates were read-only. In fact, even the subordinates themselves may not know before running if they are read-only; they could have a conditional update where the condition is not satisfied so there is no update.
  • Maximize the ability to perform unilateral aborts.
• “Normal” 2PC
  • Protocol

    Coordinator		Subordinates
    	PREPARE ⇨
    		prepared* / abort* (release locks, and forget about the xact)
    	⇦ VOTE YES / NO
    commit* / abort* (both release locks)
    	COMMIT / ABORT ⇨
    		commit* / abort* (both release locks, and forget about the xact)
    	⇦ ACK
    end (forget about the xact)

  • Log records
    • record type (prepare, commit, abort, end, undo, redo, collecting, etc)
    • unique process Id
    • unique xact name
    • coordinator Id
    • the names of the exclusive locks held by the writer in the case of prepare records.
    • subordinates Id in the case of the commit / abort / collecting records written by the coordinator.
  • Coordinator failures
    • before forcing commit * / abort*: xact is aborted by "undoing" the actions using the UNDO log records, writing an abort record, and "forgetting" it.
    • after recovery process: drive xact to commit or abort.
  • Subordinate failures
    • Before forcing prepare / abort, outcome is abort (called unilateral abort).
    • After forcing abort, outcome is abort.
    • After forcing prepare, the recovery manager contacts coordinator.
    • After forcing commit / abort; commit or abort.
• Differences between 2PC variantions
  • the number of messages sent
  • the time for completion of the commit processing
  • the level of parallelism permitted during the commit processing
  • the number of state transitions that the protocols go through
  • the time required for site recovery
  • the number of log records written
  • the number of those log records that are force-written to stable storage
• 3PC
  • In 2PC, when the coordinator sends out a PREPARE, a subordinator votes YES, then the coordinator crashes, the suborinator must then wait for the coordinator to recover before it knows what to do.
  • non-blocking
  • not wait coordinator recovery
• Presumed Abort Protocol
  • Optimize for multi-site update xacts with abort cases by forgetting xact eariler and no force-writes, and read-only xacts by no log written.
  • Commit cases

    Coordinator		Subordinates
    	PREPARE ⇨
    		prepared*
    	⇦ VOTE YES (all sites)
    commit*
    	COMMIT ⇨
    		commit* (forget after sending ACK)
    	⇦ ACK
    end (forget after all ACKs)

  • Abort cases

    Coordinator		Subordinates
    	PREPARE ⇨
    		abort (at least one, Aborting site can forget immediately)
    	⇦ VOTE NO (at least one)
    abort (and forget after sending ABORT)
    	ABORT ⇨
    		abort (others, forget at this point)

  • Pros for abort cases
    • Both coordinator and each subordinate write an abort log record, instead of force-writes.
    • The coordinator ''forgets'' xact eariler.
    • No ACK needed by subordinates
    • Coordinater need not log the names of subordinates in an abord record and write an end record
    • The recovery process for the coordinator needs not handle xact when subordinates fail.
  • Read-only xacts

    Coordinator		Subordinates
    	PREPARE ⇨
    		[write no log records] (forget after sending VOTE READ)
    	⇦ VOTE READ

  • Pros for Read-only xacts
    • Neither log written nor the second phase of the protocol if all Read Votes.
    • A nonleaf process needs only log subordinates whose vote is Yes in the commit record if none of subordinates votes No.
• Presumed Commit Protocol
  • Optimize for multi-site update xacts with commit cases by eliminating ACKs.
  • Commit cases

    Coordinator		Subordinates
    collecting*
    	PREPARE ⇨
    		prepared*
    	⇦ VOTE YES (all sites)
    commit* (and forget)
    	COMMIT ⇨
    		commit (forget at this point)

  • Abort cases

    Coordinator		Subordinates
    collecting*
    	PREPARE ⇨
    		abort* (at least one, Aborting site can forget immediately)
    	⇦ VOTE NO (at least one)
    abort*
    	ABORT ⇨
    		abort* (others, forget after sending ACK)
    	⇦ ACK
    end (forget after all ACKs)

  • Read-only xacts

    Coordinator		Subordinates
    collecting*
    	PREPARE ⇨
    		[write no log records]
    	⇦ VOTE READ
    commit

  • Crash recovery
    • A bad scenario
      1. Coordinator sends out prepare messages, then crashes. (1PC = no info for crash)
      2. Coordinator wakes up, xact is aborted.
      3. Subordinates asks ''what happened?''
      4. Coordinator has no info, says ''commit'' (bad for consistency), instead of ''collecting''.
    • Solution: force-write a collecting* log record.
• PC differs from PA
  • a nonleaf process
    • Force-writes a collecting record, and moves into the collecting state at the start of the first phase of the protocol.
    • Force-writes only abort records (except for the root process which also force-writes commit records).
    • ACKs required only for ABORTS.
    • An end record only is written after an abort record, instead of a commit record.
    • Only when in the aborting state will it, on noticing a subordinate's failure, hand over the transaction to the restart process.
    • a commit record is written and then the xact is "forgotten" in the case of a (completely) read-only xact.
  • Subordinates
    • Force-writes only abort records instead of commit records.
    • ACK only ABORTs instead of COMMITs.

Relevance

Flaws