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

Take CSRLock when observing transaction commit for migration

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.2.0-rc8, 4.3.1
    • Fix Version/s: 4.2.1, 4.3.1
    • Component/s: Sharding
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.2
    • Sprint:
      Sharding 2019-09-09
    • Linked BF Score:
      56

      Description

      Background

      When a transaction commits, it checks collections involved and adds to migration document queues if necessary. To do this, we check if a MigrationSourceManager variable exists on the CollectionShardingRuntime. Due to the fact that transactions stash locks, we skip the collection lock check assertion via the get_UNSAFE method. Skipping the collection lock assertion is fine, since we guarantee at storage commit time that collection locks are held. However, we also skip acquisition of the CSRLock.

      Issue

      Since we don't take the CSRLock, we currently have the pointer to the MigrationSourceManager and chunk cloner without any concurrency guarantees. This means that the pointer to the MigrationSourceManager can go out of scope at any time.

      Solution

      We take the CSRLock in exclusive mode in order to unregister the pointer/memory for the MigrationSourceManager. We can take the CSRLock in read mode during observing transaction commit to guarantee that we don't remove the pointer while the underlying MigrationSourceManager is in use.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: