Question

How likely is a revision conflict when using an update handler? Should I concern myself with conflict-handling code when writing a robust update function?

As described in Document Update Handlers, CouchDB 0.10 and later allows on-demand server-side document modification.

Update handlers can process non-JSON formats; but the other major features are these:

• An HTTP front-end to arbitrarily complex document modification code
• Similar code needn’t be written for all possible clients—a DRY architecture
• Execution is faster and less likely to hit a revision conflict

I am unclear about the third point. Executing locally, the update handler will run much faster and with lower latency. But in situations with high contention, that does not guarantee a successful update. Or does the update handler guarantee a successful update?

Answer 1

Update conflicts are still possible when using update handlers.

Due to the reduced “round-trip time,” the chance of an update conflict is lower
but not zero. A conflict will feel normal: a 409 response code
with this JSON:

{"error":"conflict","reason":"Document update conflict."}

I successfully triggered a conflict using the document update handler example,
and running curl twice in short succession in the shell.

curl -v -X PUT \
http://localhost:5984/db/_design/app/_update/accumulate/my_doc?amount=10 \
& curl -X PUT \
  http://localhost:5984/db/_design/app/_update/accumulate/my_doc?amount=1

One of the curl responses (randomly) was a 201 and the other a 409.

Document update handlers do not fundamentally change CouchDB

Updates are subject to conflicts, as well as validation failures (401 Unauthorized,
403 Forbidden, etc.)