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

Implement transactions documents persistence

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

      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@mongodb.com Randolph Tan
            Reporter:
            kaloian.manassiev@mongodb.com Kaloian Manassiev
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: