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

Retry on predicate unique index violations of update + upsert -> insert when possible



    • Type: Improvement
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Write Ops
    • Labels:
    • Case:


      Issue Status as of Jan 27, 2017

      During an update with upsert:true option, two (or more) threads may attempt an upsert operation using the same query predicate and, upon not finding a match, the threads will attempt to insert a new document. Both inserts will (and should) succeed, unless the second causes a unique constraint violation. This MongoDB behavior is documented here.

      It is expected that the client will take appropriate action upon detection of such constraint violation. Appropriate action may vary depending on individual application requirements.

      This ticket tracks the cases where the server can automatically retry performing the upsert as an update rather than requiring the client to do so. Those scenarios are limited to cases where the violated unique constraint is an exact match to equality in the query predicate of the update operation (and no other fields being tested in the predicate). Only then could the server safely retry the upsert operation as an update/upsert.

      Original description

      It is possible that two updates come in with upsert:true, resulting in neither finding a document and both inserting new documents which conflict on unique index violations of the query predicate. In this case it is possible for the server to retry any failed updates.

      Currently clients can retry the update to get the same behavior which is expected from the server.

      This affects both updates and findAndModify. See SERVER-10350 for slightly more background.


          Issue Links



              • Created: