Page Comparison

...

During garbage collection stage, we cannot utilize the distributed durable information about votes. We are switching to regular 2 phase commit. (JO: can you explain a bit more about what you're trying to achieve in this stage?  Is it just to finalize server state about the transaction? Do we have to be prepared for the client retrying after GC?)

1. RPC(5): as a DM detects the expiration of a client lease, it checks whether there is unacknowledged transaction information, and sends “StartCleanup” request to recovery coordinator of each transaction (the server with 1^st entry in list of keyHash).
   1. Request: <clientId, list of <tableId, keyHash, rpcId>>
   2. Handling: recovery coordinator initiates cleanup protocol. Possible optimization: use UnackedRpcResults to avoid duplicate cleanups/recoveries.
   3. Response: Empty
2. RPC(6): Recovery coordinator sends requestAbort to clean up & release all locks in masters.
   1. Request: <clientId, seq#>
   2. Handling:
      1. checkDuplicate with given clientID & seq#
      2. if exists, respond with saved results.
      3. If not, respond “ABORT-VOTE”
   3. Response: COMMIT-VOTE | ABORT-VOTE
3. Check if COMMITED set has this TX’s record (JO: I'm not sure what this meansthis means; should this happen before RPC 6? Why is the COMMITTED set needed?). After recovery coordinator collects all votes, durably log outcome of TX (only if outcome is COMMIT) & add to COMMITED set and send decision & order clean up.
   1. Request: <DECISION, clientId, rpcId in RPC(6)>
   2. Handling:
      1. Check a lock is grabbed for rpcId
      2. If a lock was grabbed, flush the buffered write (detail is same as normal operation.) and unlock the object.
      3. Clean up RpcRecord by manually marking “acked” on UnackedRpcResults. Refactoring UnackedRpcResults is required to support marking “acked” and shrinking its window accordingly. We delete the whole client information as soon as all TX are marked as “acked”.
      4. Respond ACK.
   3. Response: ACK (empty)
4. Recovery coordinator deletes the logged result (written in 7) of transaction (appending tombstone for the TX outcome entry). It is now safe to remove the TX’s record from COMMITED set.