Page Comparison

...

1. Client sends MT ("minitransaction") to master
   • predicates: list of (table id, oid, version)
     • If the transaction commits, the object must have the given version at the time the decision is made. If the object has some other operation applied to it below, it must additionally not be modified until the operation is applied.
   • writes: list of (table id, oid, data, indexes)
     • If the transaction commits, the data and index entries will be stored in the object.
   • creates (with server-assigned keys): list of (table, data, indexes)
     • If the transaction commits, the data and index entries will be stored in a new object.
       • How will the client get to know which object this is? Either the master will have to delay returning the outcome to the client or the participant will have to allocate the ID before the decision to commit is made.
   • deletes: list of (table id, oid)
     • If the transaction commits, the object will be deleted.
   • reads: list of (table id, oid)
     • If the transaction commits, the data and index entries will be returned.
     • Doing reads outside the transaction and then sending a transaction consisting of predicates for the versions that were read is the optimistic alternative to this. Do we want to support pessimistic reads inside transactions?
2. Master writes transaction object with list of participants, acquiring a txid
3. Master sends txid, MT to all participants
   • By sending the txid and MT, the master guarantees to send the participants a decision eventually.
4. Participants lock objects and log MT
5. Participants send vote to master
   • If they vote no, they can unlock their objects and forget all about the transaction.
   • If they vote yes, they guarantee to keep their objects locked until they learn the decision
     and to be able to commit if that is the decision (i.e., they persist the intent of the MT).
6. If the decision is yes, the master notes it in the transaction object
7. Master relays decision to participants
8. Master sends response to client
9. Participants commitIf the decision is yes, the participants commit. Otherwise, they unlock/roll back.
10. Participants sends commit acknowledgement to master
    • By sending When the master receives their commit acknowledgement, they guarantee to never ask the master about txid again.
    Master removes transaction object
    • acknowledgements, it may logically remove them from the participants list.
11. Master removes transaction object
    • There are no more participants and the clients have no way to refer to the transaction. It is complete.

If the client crashes after sending the MT:
The application never learns of the decision. The MT will still commit or abort.

If the master crashes before writing the transaction object (step 2):
The client's RPC library will retry.

If the master crashes before removing the transaction object (step 11):
When the master recovers, it must scan its transaction objects. For each transaction object that does not have a decision to commit, the master assumes it aborted. For each transaction that does, the master knows it committed. It picks back up by relaying the decision to participants (step 7). Participants that have no record of the transaction should simply agree to this.