I looked into various documentation around durability requirement and kind of exception that can occur during such operation. i would like to know more about DocumentConcurrentlyModifiedException, Even though everywhere it is said that it should be treated in similar way as CASMismatchException, is it true in all cases?
- When this exception occurs, the original mutation operation has not updated the managed cache nor persisted the change in master node, is it a valid assumption? If not then it cannot be considered similar to CASMismatchException.
- When exactly this exception is thrown including failover scenarios?
This link talks about CASMismatchException, where a user can retry the operation as it clear that the mutation operation is not persisted to disk or managed cache.
Based on Sample provided in the page.
- Why Application A will be getting DocumentConcurrentlyModified exception?
- Did the changes done by Application A is persisted in master node?
- Should application B be getting CASMismatchException, in this scenario rather than a durability error for Application A?
Imagine that the application A mutates document D and gets a CAS returned. Then it starts polling. Slightly afterward, application B also mutates document D and the CAS value changes again. The managed cache on the server performs deduplication, or the document can be replicated between poll cycles. Therefore, the CAS returned to application A might never be observed since it already changed to the CAS from application B.
To detect this scenario, once the CAS on the master changes the SDK will raise a DocumentConcurrentlyModifiedException. How to react depends on the nature of the application. If from the semantics the latter operation subsumes the previous one, ignoring the error might be acceptable. If not, application A needs to fetch the document again, perform its changes or raise an error. In general, error handling is very similar to a CASMismatchException.