yuval-a / deriveODM

DeriveODM is a reactive ODM - Object Document Mapper - framework, a "wrapper" around MongoDB, that removes all the hassle of data-persistence by handling it transparently in the background, in a DRY manner.
MIT License
4 stars 0 forks source link

Atomic selects #4

Open Enelar opened 2 years ago

Enelar commented 2 years ago

In some corner cases I have to be sure that:

Usually I did the temp lock of a document with updateOne method. With match pattern like {locked: {$lt: now()}} and update {$set: {locked: 'now() + 30 sec'}. Every success update were returning me exclusively used document (for lock time duration). How to achieve same results with your library?

How to run updates on database at all?

yuval-a commented 2 years ago

Hi Enelar. To run updates on a DB - simply change values of (non-meta) properties of a data instance (either created a new, or retrieved from a DB via one of the get functions), the engine will know to send update operations to the DB in an optimized way.

If there are concurrent changes/updates to the same instance - the last one entered to the queue will be the one that will reflect the document on the db.

Regarding several services running updates on the same collections/documents - to prevent race-conditions - you should add another messaging layer (like a message server) connected to all the services, the messaging service will use Derive and will be connected to the DB -- all the services will be connected to the messaging service -- instead of sending direct "updates" or other DB operations - they will send "messages" (what to update, what to insert etc.) - then the messaging server will actually trigger the DB operations themselves according to the messages.

You can implement the messaging server as a simple HTTP server with queues, or use more robust ready solutions like RabbitMQ.

I have plans to perhaps write a dedicated messaging service for this purpose.

yuval-a commented 1 year ago

Further anecdotes on this issue, a year after with new features: