Implement transactions documents persistence

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 3.5.10
    • Affects Version/s: None
    • Component/s: Sharding
    • None
    • Fully Compatible
    • Sharding 2017-05-29, Sharding 2017-07-31
    • 0
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      This task is about implementing an API to initialize and write entries in the admin.system.transactions collection, according to the guidelines in the design.

      As part of this task we need to figure out:

      • What the API should look like, its concurrency rules (i.e., what locks need to be held, where are the write unit of work boundaries, etc)
      • How to best capture the write outcome information and put it in the transactions document (this includes the n, nModified, etc statistics which are generated at a location, which is outside of the oplog generation)
      • Whether some form of caching is necessary

      It does not include preventing replication of the admin.system.transactions collection, which is covered by SERVER-28902.

      Update:
      New design will be such that the transactions document will not store the write results, but a pointer to the oplog entry of the last write. In addition, the oplog entries will now have a prevTs field that will link to the previous write in the same transaction. By following the chain of oplog entries, it is possible to determine which writes happened as well as the results for them

              Assignee:
              Randolph Tan
              Reporter:
              Kaloian Manassiev
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: