CODEWITHSUNDEEP
concurrencycouchbase
Murtaza Mandvi
Murtaza Mandvi

Reputation: 10988

Couchbase read / write concurrency

I have a question regarding how does Couchbase internally handle concurrency.

I tried researching in their documentation and all I found was that it depends on which locking mechanism you use in your application, the two main being :

  1. Optimistic locking
  2. Pessimistic locking

However, both of the above are related to how we want our strategy to be for saving data , meaning if we prefer to lock it or not.

In our case, IF we are not using either of those locking in our application, how would couchbase serve the document in the scenario below :

  1. If application A writes a document A
  2. At the very same instance application B tries to read Document A

My question is will Application B have to queue up to read the document, or by default it will get served the older version (all of this is not going through sync gateway and we are using .Net DLL directly for writing and reading).

Couchbase version 4.5.0

Upvotes: 2

Views: 1642

Answers (2)

David Ostrovsky
David Ostrovsky

Reputation: 2481

Because, as Kirk mentioned in his reply, Couchbase is consistent, both the read and write requests in your scenario will go to the same node and access the same object in the server's memory. However, concepts like "at the same time" get fuzzy when talking about distributed systems with network latency and various IO queues involved. Ultimately, the order of execution of the two "simultaneous" requests will depend on the order that the server receives them, but there is no deterministic way to predict what it will be. There are too many variables on the way; what if the CLR of one of the client decides to do garbage collection just then, delaying the request, or one of the client machines experiences momentary network lag, etc. This is one of the reasons that the documentation recommends using explicit locking for concurrent writes, to enforce predictable behavior in the face of unpredictable request ordering.

In your scenario though, there is simply no way to know in which order the write and read will occur, because "at the same time" is not an exact concept. One possible solution in your case might be to use explicit versioning for the data. This can be a timestamp or some sort of revision number that's incremented every time the document is changed. Of course, using a timestamp runs into a similar problem as above, because it's recorded according to the clock of the machine application A runs on, which is most likely different from the clock where application B runs.

Upvotes: 3

NoSQLKnowHow
NoSQLKnowHow

Reputation: 4855

If you are using the Couchbase SDK and connecting directly to the Data Service, Couchbase is strongly consistent. If application A writes the document and immediately after application B reads it, application B will get that version. The consistency comes from how Couchbase distributes the data and how the client SDK accesses it. Couchbase distributes each object to one of 1024 active shards (Couchbase calls them vBuckets). There are replicas, but I will not get into that here. When the SDK goes to read/write objects directly, it take the object ID you give, passed it into a consistent CRC32 hash. The output of that hash is a number between 0-1023, the vBucket number. The SDK then looks into the cluster map (a JSON document distributed by the cluster) and finds where in the cluster that vBucket lives. The SDK then goes and talks directly to that node and vBucket. That is how application A can write an object and then microseconds later application B reads it. They are both reading and writing to the same place. Couchbase does not scale reads from replicas. Replicas are only for HA.

Upvotes: 3

Related Questions