For the new distributed commit transaction, we also need to change the way we handle prepare commit and rollback. If we write a prepared update to disk, the older update inserted to the history store has a max stop timestamp. In the current implementation, if we commit the prepared update, we need to goto the history store to fix the timestamp of that record. In the new model, we can no longer do that, because the commit timestamp of the prepared update may not be stable and we will continue to write a prepared update in the next reconciliation. The stop timestamp of the history store record should remain as max.

I have an immature idea to solve that. Instead of fixing the timestamp in the commit flow, we have to restore the history store record back to the update chain and mark it to be deleted from the history store as the rollback case does, which means more cache usage. For any update needs to be deleted from the history store, we also cannot delete them outright in the next reconciliation. We have to wait until the associated prepare commit or rollback to become stable. Only then we can delete the update from the history store.