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

Consider implementing a cursor 'reserve' feature

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Storage
    • Storage Execution

    Description

      This came up as a part of the resharding project, as resharding oplog application is subject to write skew. An initial thought was that if the server had a reserve feature that exposed WT's reserve method, we could use this to generate write conflicts and avoid write skew. For now, we have instead implemented functionality that will first read a doc, and then do an unreplicated no-op update on this doc in order to get the desired behavior. After speaking with louis.williams , we think that it's still worthwhile to consider implementing a 'reserve' feature to be used instead because:

      1. This code path will be executed for every oplog entry a given resharding recipient applies, and a 'reserve' method would have less of an impact on the WT cache.
      2. 'reserve' would not generate oplog entries, and so wouldn't need any extra code to avoid generating oplog entries that we have now

      Attachments

        Activity

          People

            backlog-server-execution Backlog - Storage Execution Team
            janna.golden@mongodb.com Janna Golden
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated: