Is the mutateIn increment operation atomic?

Java SDK
1

Hi, we wonder about mutateIn increment operation.

Subdocument operations in the document are said to be atomic. Sub-Document Operations with the Java SDK | Couchbase Docs

Sub-Document operations are also atomic, in that if one Sub-Document mutation fails then all will, allowing safe modifications to documents with built-in concurrency control.

The Counters and Numeric Fields section is the same as the FullDocument operation is the same as logic. Sub-Document Operations with the Java SDK | Couchbase Docs

Counter operations allow the manipulation of a numeric value inside a document. These operations are logically similar to the increment and decrement full-document operations:

As an example,
foo: {“count”:0}
we want to increase the count field of the two thread foo document or more thread…

final List<MutateInSpec> specs = Collections.singletonList(MutateInSpec.increment("count", 1));
genericRepository.mutateIn(collection, specs, documentId);

What do we see as value? 1 or 2

I know that if I do this with atomic counter, it will be 2. Key Value Operations | Couchbase Docs

2

Hi @suleymancan
You will see 2.

3

Thank you for answer @graham.pople
So, Mutate in increment operation atomic? We say hundreds of threads will increase the same field of the document correctly?

Not clearly written in these documents. Confusing.

4

Yes, that’s correct. Under the hood the server is doing a fetch-modify-write loop, using CAS (opportunistic concurrency) to detect if the document has changed between the fetch and write, and going through the loop once again if it has.

I’m sorry to hear that it’s not clear in the documentation. Pinging our SDK documentation experts @Richard_Smedley @Maria_Shodunke @hakim.cassimally so they can take appropriate action.