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

runAggregate should be refactored so that locking isn't so confusing

    XMLWordPrintableJSON

Details

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

    Description

      My particular angle of motivation on the refactor is from SERVER-67424 wherein I encountered the following problem:

      "It appears that we modify read concern settings (prepared conflict) in DocumentSourceWriter. The problem with this is that if the high level code has a AutoGetLockFree*, we've already got a storage snapshot open: read concern is normally manipulated in the AutoGet* or earlier layers. It works today because we happen not to hold AutoGet* across runAggregate's use of DocumentSourceWriter. I was trying to hold locks across this, to hold a lock across registration of CursorManager::registerCursor for concurrency control with replication rollback."

      Locking uncertainty in runAggregate hinders development: it's very confusing.

      Attachments

        Activity

          People

            backlog-query-execution Backlog - Query Execution
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated: