CODEWITHSUNDEEP
javascriptasynchronouscouchdb
user3301565
user3301565

Reputation: 402

Database cluster - asynchronous tasks

Let's say I have a couchDB database called "products" and a frontend with a form. Now if a user opens a document from this database in the form I want to prevent other user from editing this specific document.

Usually pretty simple:

-> read document from couchDB
-> set a variable to true like: { edit : true }
-> save (merge) document to couchDB
-> if someone else tries to open the document he will receive an error, becaus of edit:true.

BUT, what if two user open the document at the exact same time? The function would be called twice and when the second one opens the document he would falsely receive an edit:false because the first didn't had enough time to save his edit:true. So how to prevent this behaviour?

First solution would be: Build an array as a cue for database requests and dont allow parallel requests, so all requests would be worked off one after another. But in my opinion this is a bad solution because the system would be incredible slow at some point.

Second solution: Store the documentIDs of the currently edited documents in an local array in the script. This would work because this is no asynchronous process and the second user would receive his error immediately.

So far so good, BUT, what if some day there are too many user and this system should run in a cluster (the node client server, not the database) - now the second solution would not work anymore because every cluster slave would have its own array of documentIDs. Sharing there would end in another asynchronous task and result in the same problem above.

Now i'm out of ideas, how do big clustered systems usually handle problems like that?

Upvotes: 0

Views: 35

Answers (1)

Dominic Barnes
Dominic Barnes

Reputation: 28429

CouchDB uses MVCC to maintain consistency in your database. When a document is being updated, you must supply both the ID (_id) and revision number (_rev) otherwise your change will be rejected.

This means that if 2 clients read the document at revision 1 and both attempt to write a change using that same revision number, only the first will be accepted by the database. The 2nd client will receive an error, and it should fetch the latest revision of the document in order to proceed.

In a single-node environment, this model prevents conflicts outright. However, in cases where replication is occurring, it is still possible to get conflicts, even when using MVCC. This is because conflicting revisions can technically be written to different nodes before they have been replicated to one another. In this case, CouchDB will record the conflict and your application is responsible to resolve them.

CouchDB has stellar documentation, in particular they have an article all about conflicts and replication that I highly recommend for this subject.

Upvotes: 2

Related Questions