Concurrent update to same field in mongodb

Working with Data
1

I have the following schema:
unique_doc_id: {
title: title1,
desc: desc
listField:
mapField:
}

I have a system1which hosts an API used to take inputs for above document…then notifies system2 using an unordered queue which is supposed to update this document in the DB.

I want to maintain field level timestamps for concurrent updates on same field for the following scenario:
Let’s say someone calls API at T1 with title1, at T2 (T1 + 1ms) with title2…but the updates reach system2 out of order i.e. the T1 update reaches AFTER T2 update. i.e. let’s say the write of title2 happens first, so, when the title1 update reaches system2, that write should fail…I beleive this can be done with field level timestamps…

Does mongoDB have support for this ??
Any doc links / example code chunks would help.

Thanks!

2

Could have a last updated field or checksum stored in the document, when you write you pass in the last known checksum. If it’s different then you know something else has modified it since your last read and can deal with it appropriately.

3

Hello, @Yash_Verma2 and welcome to the community! :wave:

To solve your problem, you can add a field in your document, that would represent the timestamp when the update command is received. Update the document only if your update command has the greater timestamp.

Example dataset:

db.books.insertOne({
  title: 'title0',
  modificationsReceived: 1691360130000
});

If the following command reach the database first:

db.books.updateOne(
  { 
    modificationsReceived: {
      $lt: 1691360130002
    },
  },
  {
    $set: {
      title: 'title2',
      modificationsReceived: 1691360130002
    }
  }
);

Then this one will not make any changes to your data

db.books.updateOne(
  { 
    modificationsReceived: {
      $lt: 1691360130001
    },
  },
  {
    $set: {
      title: 'title1',
      modificationsReceived: 1691360130001
    }
  }
);
2 Likes
4

Using a timestamp to order the events can work most of the time, but not 100% guaranteed.

This is because wall clock time is not reliable and you can have clock drift in a distributed system. To achieve 100% guarantee, you will have to create your own virtual clock for ordering.

Check my comments in I am curious about how $currentDate works - #3 by YounWan_Kim

5

Thank you. I will try this one using java driver