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.
@pccb if weâre talking about KV reads & writes then no this sentence does apply (though Iâm not sure on its source). Itâs only writers that can block writers - and usually only briefly.
Writers donât block readers, because you can read documents all day, and theyâre not going to be interrupted, or need to retry, or be blocked in any way, by writes.
And readers donât block writers for basically the same reason.
Itâs only when you have two writers trying to write the same document that you inevitably have a conflict. And Couchbase gives you great tools to handle that conflict, as Mike says, in a very efficient and minimally-impacting way. Resolving a single-document write conflict with optimistic concurrency (e.g. you do a read-modify-write, hit a CASMismatch, and do the read-modify-write again), is all going to resolve in a millisecond or two.
thanks @graham.pople
When you have two or say five writers trying to write the same document, and any of those tools are not used, I believe the writes are queued, even if only for a fraction of a second, with each write happening one after the other. Is that correct?
I believe the writes are queued, even if only for a fraction of a second, with each write happening one after the other. Is that correct?
If cas is used, then the first write will succeed and subsequent writes will fail with cas-mismatch.
If cas is not used, then all the writes will succeed.
If the requests were made concurrently, such that one request would need to queued for another request - there is no way to influence the order. Even from the same thread in the same client making (reactive or asynchronous) requests on the same document in a particular order does not guarantee that they are executed in that order (they will be executed in order under certain conditions in some SDKs, but there is no guarantee - so you could make a test to show they are executed in order - but there is no guarantee, and that might change). If the client determines the order - by waiting for one request to complete before making the next request - there is no queuing.