Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-39364

Audit uses of setLastOpToSystemLastOpTime

    XMLWordPrintableJSON

Details

    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.3.3
    • Replication
    • None
    • Fully Compatible
    • Repl 2019-12-30, Repl 2020-01-13, Repl 2020-01-27
    • 20

    Description

      It is not valid to call setLastOpToSystemLastOpTime() and then wait for majority writeConcern to ensure that any data read was majority committed. The reason is that writes update the lastApplied in an on-commit hook after the data changes are made. Consider the following scenario. Originally the lastApplied is time 1. Operation A updates the document {_id: 0} to have a=5 and writes an oplog entry with time 2. Operation B reads the document {_id: 0, a: 5}.  Operation B calls setLastOpToSystemLastOpTime() and gets the lastApplied time as time 1. Then the on-commit hook for Operation A updates the lastApplied to time 2. Operation B will wait for the majority commit point to reach time 1, which does not guarantee that the data that it read was majority committed.

      Any callers of setLastOpToSystemLastOpTime() that use it to ensure data read was majority committed are suspect. This excludes reading transaction state in transaction operations, since they are serialized by the session checkout mechanism, so a new transaction operation cannot start until the on-commit hooks have finished for the previous operation.

      Attachments

        Issue Links

          Activity

            People

              lingzhi.deng@mongodb.com Lingzhi Deng
              tess.avitabile@mongodb.com Tess Avitabile (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: