I am curious about how $currentDate works

Working with Data Drivers & ODMs
, , ,
#1

hello. I am a developer trying to develop an application with MongoDB as the main repository. If you have any questions, please leave a question.

The project I am currently developing has application instance group A and application instance group B. Both operate as multi-instance, group A saves documents in DB in parallel, and group B reads and uses documents stored by A.

There is one limitation here. The point at which the document is stored in the DB is very important. When Group A’s instances save documents in parallel, they need to be able to recognize exactly when a document is saved to the DB when Group B retrieves a document.

Therefore, I would like a feature where MongoDB, not the application, automatically initializes the document’s creation-time fields when the document is saved.

To solve this, I initially tried to use ObjectId. From reading the official description, it’s because when you save the document, if you leave the _id field blank, it automatically initializes the field, and the ObjectId contains a timestamp within it. However, reading the official description, if the _id field is empty, it is initialized by the driver, not the DB, so this couldn’t be a solution.

I found $currentDate as another solution. If you use $currentDate when upsert the document, this also seems to satisfy your requirements.

I have a question for you here. Where does the logic to initialize the time run when a document is upsert using $currentDate? I’d like it to be initialized to the server’s native time, but I don’t think I can use this workaround if the document is initialized using the application’s system time.

Thanks to everyone who replies. :slight_smile:

ps. sorry for my english skill.

#2

the time difference between driver and db server may be only 10ms, does it really matter for your case?

There’s no global wall clock across computers. Even with NTP, there will be clock drift. So if you really need a “100% accurate timestamp”, don’t use wall clock. Instead use virtual time. (e.g. lamport clock).

So i suggest you revisit your use case and/or refine your design.

1 Like
#3

Thank for replying :slight_smile:

I have one more question. If I use $currentDate when instances in group A take turns saving data, can I guarantee the relative chronological order between the saved data?

Let’s give an example. Let’s say we have instances 1 and 2 in group A, and data 1 and 2 need to be processed by instance 1 and 2, respectively. Let’s assume that data 1 and data 2 are imported into group A in order.

  1. Data #1 is consumed into instance #1.
  2. Instance #1 is trying to process data #1 and store it in the DB, but the save is being delayed due to some issue (network problem, etc.).
  3. Data #2 is consumed into instance #2.
  4. Instance #2 successfully saves data in the DB, and timestamp2 is recorded.
  5. The issue of instance #1 is resolved, and data #1 is saved to the DB, and timestamp1 is recorded.

Timestamp1 must not be less than timestamp2 in this process because the relative point in time at which data is stored is important.

Could $currentStamp solve this problem?

Concurrent update to same field in mongodb
#4

i think you need to get a better understanding on “ordering” in a distributed system.

A relative point in time can not be represented by a wall clock timestamp (in this case). Because if there’s no “happen before” relationship between two events, then we consider the two events as “concurrent”, meaning no one happens before the other.

In your example case, there’s no happen before in data 1 and data 2, so how do you know which one goes first?

No, you don’t.

Check out happen-before/message-ordering/lamport-clock/… concepts on Internet.

To give you an example, if the same client sends msg1 first, then sends msg2, then we say: msg1 happens before msg2.

1 Like
#5

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.