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

Atomicity of Upserts on multi field unique index

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 2.4.4
    • Component/s: Concurrency, Write Ops
    • None
    • Environment:
      Red Hat Enterprise Linux Server release 6.3 (Santiago)
      Linux 2.6.32-279.22.1.el6.x86_64 #1 SMP Sun Jan 13 09:21:40 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
    • Linux

      We're getting a handful of live exceptions resulting from concurrent upserts, with the same query, complaining about unique index violations. It was my understanding that the upsert process would be atomic, with respect to the decision to update or insert, and therefore the 'winner' of the obvious race condition would perform an insert and second place would update the new document.

      An example of the exception:

      com.mongodb.MongoException$DuplicateKey: {
      "serverUsed" : "localhost/" ,
      "singleShard" : removed,
      "err" : "E11000 duplicate key error index: index-name dup key:

      { key-entry }

      " ,
      "code" : 11000 ,
      "n" : 0 ,
      "lastOp" :

      { "$ts" : 1374832745 , "$inc" : 4}

      "connectionId" : 26451 ,
      "ok" : 1.0}

      The unique index in this case is a composite of four fields, one guid, the others are shorter strings all contained within a sub-document. The query element of the upsert consists solely of the unique index fields, the update is a document containing a single field $inc and a $set for half a dozen other fields. I would post an example, but i've been unable to recreate the issue with test code. The database is not under significant load (~100 updates per second, ~4% locked, rarely a single item in either write or read queues), the concurrent queries would be coming from separate clients, so not the same connection pool. The upserts are operating within an "ensureConnection" block (java driver), so we can check a variety of write concerns.

      It's my understanding this shouldn't be happening. Is there any extra information you need to help confirm this issue and track it down?

            Unassigned Unassigned
            tcoupland Tom Coupland
            0 Vote for this issue
            6 Start watching this issue