I realize that the approach in SERVER-100343 is not correct because the in-memory transaction table data written to the oplog does not represent a consistent point in time due to oplog holes and what is worse is that it may contain data that is susceptible to rollback.

This ticket proposes a new approach to have a background thread running on primary that tails the oplog up-to the stable opTime and periodically persist the in-memory transaction table as noop oplog entries.