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

Design a general solution for concurrent access problem in ShardingDDLCoordinator

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Catalog and Routing
    • 2

      As part of SERVER-70580 a quick-fix has implemented to prevent data race access on getDatabaseVersion 

      The solution is based on save as const member of the ShardingDDLCoordinator the object instances of the StateDoc that do not change among different phases or after a step-down recovery. Those member can be safely accessed as reference among different thread.

      At the moment, the design is the following:

      • Getter methods return references as much as possible as optimisation
      • Any public method can be accessed by external threads. Any of those methods requires locking, copies or access to const member to prevent data race.
      • Any private/protected method is accessed only by the coordinator, ensuring serialisation.

      However, given the design of the class, the problem might present itself again.

      In the future we might need to access other informations turning private or protected methods as public, or simply by creating new public methods.

      The engineers have to make sure that:

      1. lock + a return by copy is implemented in case the data accessed might change.
      2. Reference is retuned by getters only for const member.  

      This is not expressed clearly by the current design, leading to possible data races at every small change.

      Note: the solution should also be back-ported.

            Assignee:
            Unassigned Unassigned
            Reporter:
            enrico.golfieri@mongodb.com Enrico Golfieri
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: