I have a few questions regarding how Couchbase database system handles concurrent operations on the same document.
Please refer to the following example for context:
Couchbase Bucket: trans2
Document: POE-1000009261
Questions:
Does Couchbase allow concurrent write requests from two different applications for the same document on same time(POE-1000009261)?
While one instance is updating the document (POE-1000009261), does Couchbase allow another instance to read the same document simultaneously?
Are there configuration parameters which we can use to tune the locking mechanisms which we can use for couchbase database system or for applications?
@graham.pople Thanks for sharing the docs. I had gone through but still not able to get clarity on my point-2. If a CB instance updating a document then how another instance read the same doc simultaneously. How this mechanism works.
Reads and writes of a document are atomic. One always occurs before the other. There is no actual concurrent access, but applications can make “concurrent” accesses without issue.
yes @mreiche , I just want to know how applications are getting accessed when these kind of situation arises. In case of RDBMS if a transaction is getting update and if same time other application trying to read, DB will read from redo entries (before image of that transaction) and share it to the end user.
In similar way how it happens in case of couchbase. If you provide any blog reference it will helpful .
An “update” requires a read followed by a write. Please refer to the couchbase documentation for optimistic locking, pessimistic locking and transactions.
If you’re doing KV operations: if you’re reading a doc and then writing it, you will generally use optimistic locking to detect modifications from other writers. This works by you providing the document’s CAS value (from the read point) when you write it. If the document has been changed by another actor, you will get a CasMismatch error.
There is also pessimistic locking available via getAndTouch(), but generally optimistic locking is the preferred mechanism.
So, ‘readers don’t block writers and writers don’t block readers’ doesn’t apply in the strictest sense, and probably shouldn’t be used, right? It’s not really ‘felt’ because it happens so quickly, but it’s not truly ‘simultaneous’ either—correct?
Reads and writes must be atomic with respect to each other. Reads and writes cannot occur simultaneously. Otherwise the read could return part of the old document and part of the new document. Isn’t this what we all assume? Likewise two writes cannot occur simultaneously. And the last write wins. I suppose multiple reads can occur simultaneously. I’m assuming this - because how else would it work? And to an application - what does it matter as long as the result is consistent?
But I think most people are concerned with the whole read - modify - write occurring concurrently with another read - modify - write. Which is managed by the application with optimistic locking, pessimistic locking or transactions.