ISSUE DESCRIPTION AND IMPACT

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. .

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.

IMPROVEMENT DESCRIPTION

As part of SERVER-37124, fixed in versions 4.1.6 and later, the server will automatically retry performing the upsert in cases where it is detectably safe to do so. It is safe for the server to retry when the following conditions hold:

The following table contains examples of upsert operations that the server can automatically retry on DuplicateKey error, and examples where the server cannot automatically retry:

kp                                                             update                    server will retry

{_id: 1}

db.coll.update({_id:5}, {$set:{a:5}}, {upsert:true})

yes

{a:1}

db.coll.update({a:{$in:}}, {$set:{b:5}}, {upsert:true})

yes

{a:1,b:1}

db.coll.update({a:5,b:7},{$set:{c:5}}, {upsert:true})

yes

{a:1,b:1}

db.coll.update({a:5,b:7},{$set:{a:7,c:5}},{upsert:true})

no, since a is in kp and is mutated

{a:1}

db.coll.update({_id:5},{$set:{b:6}}, {upsert:true})

no, since the predicate does not contain a

{_id:1}

db.coll.update({_id:5,v:6},{$set:{a:5,b:6}}, {upsert:true})

no, since v is not in kp

{a:1}

db.coll.update({a:{$lt:5}},{$set:{b:5}}, {upsert:true})

no, since the predicate on a is not an equality

This ticket will now be resolved as duplicate of SERVER-37124 since we don't believe there is further work that we can do on the server and the application must correctly determine whether the operation that failed can be safely retried again or not.

VERSIONS

This improvement in SERVER-37124 will be included in the 4.2 production release