Consensus on Transaction Commit

1. Introduction

A distributed transaction is performed at multiple sites, terminated by a request to commit or abort (the intension). The sites then use a transaction commit protocol to decided whether to commit or abort (the actual result).

Focus on atomicity: all or nothing is committed on the sites.

2. Transaction Commit

A distributed transaction is performed by a collection of processes called resource managers (RM).

For the transaction to be committed, each RM must be willing to commit it (必要不充分).

Each RM begins in a working state. The goal of the protocol is for the RMs all to reach a committed or aborted state.

Two requirements:

• Stability: Once an RM has entered the committed or aborted state, it stays there forever.
• Consistency: It is impossible for one RM to be in the committed state and another in aborted state.

As a result, once an RM enters committed, no other RM can enter aborted, and vice versa.

In addition, each RM also has a prepared state. Requirement:

• An RM can enter the committed state only after all RMs have been in the prepared state.

So for a transaction to be able to commit, these sequence of events must happen:

1. All RMs enter the prepared state, in any order
2. All RMs enter the committed state, in any order

At last, an RM is allowed to enter aborted directly from working state.

• Initial Predicate: All RMs are in the working state.
• Next-state relation: asserts that each step consists of one of the following two actions performed by a single RM:
  • Prepare: An RM can change from the working to prepared state.
  • Decide:
    • If an RM is in prepared, and canCommit() is true, then this RM can go to committed.
    • If an RM is in {working, prepared}, and notCommitted() is true, then it can transition to aborted.

The predicated mentioned earlier:

• canCommit(): true iff. all RMs are in {prepared, committed}.
• notCommitted(): true iff. no RM is in committed.