-
|
In some cases, the database allows you to update the same document with the same revision twice. DescriptionSometimes, when two processes update the same document at the same time (5-150 ms between requests) with the same initial revision, both requests complete normally without creating conflicting documents, and the database keeps both updates with consistent revisions. All requests are sent to the same cluster instance. Step by step:
Then i have three revisions in database - 1, 2 and 3. How did I even know this was happening? I started adding the previous version on every update to debug the strange behavior of my service. Steps to ReproduceI cannot reproduce this error locally or in a development environment, but it sometimes happens in a production environment. Expected BehaviourA 409 response from one of requests or a document conflict within the database. Your EnvironmentCouchDB in cluster mode. 3 instances of CouchDB on three nodes.
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
HI @vd2org, this is expected behaviour for a CouchDB 2.x or 3.x cluster. CouchDB 2.x and 3.x do not make any sort of immediate consistency guarantee, nor that you will "read your writes." It is an eventually consistent system. I describe the scenario you're experiencing in great detail in my slide presentation. Start on Slide 7, which covers CouchDB 1.x, and then continue to slides 13-20, which explain the exact scenario you encountered. The beauty of CouchDB is that all accepted changes (for which you receive a 201 or 202 response) end up in the database. If you're able to detect the difference between a 201 and a 202 response, you can identify when this occurs at runtime. CouchDB 4.x will eventually change this behaviour, but it is still on the horizon. For now you should plan to both look for 202 responses when updating a document, as well as performing periodic conflict detection scans across your entire database. |
Beta Was this translation helpful? Give feedback.
-
|
This means it is normal that when two requests update one document with same revision at the same time without conflicts? |
Beta Was this translation helpful? Give feedback.
HI @vd2org, this is expected behaviour for a CouchDB 2.x or 3.x cluster.
CouchDB 2.x and 3.x do not make any sort of immediate consistency guarantee, nor that you will "read your writes." It is an eventually consistent system.
I describe the scenario you're experiencing in great detail in my slide presentation. Start on Slide 7, which covers CouchDB 1.x, and then continue to slides 13-20, which explain the exact scenario you encountered.
The beauty of CouchDB is that all accepted changes (for which you receive a 201 or 202 response) end up in the database. If you're able to detect the difference between a 201 and a 202 response, you can identify when this occurs at runtime.
CouchDB 4.x wi…