Team, I have been trying to understand how setting retry_on_conflict will behave. It is little confusing in the documentation.
As per my understanding, below lines suggest that the latest version update will be handled by retry_on_conflict
To avoid losing data, the update API retrieves the current _version of the document in the retrieve step, and passes that to the index request during the reindex step. If another process has changed the document between retrieve and reindex, then the _version number won't match and the update request will fail.
For many uses of partial update, it doesn't matter that a document has been changed. For instance, if two processes are both incrementing the page-view counter, it doesn't matter in which order it happens; if a conflict occurs, the only thing we need to do is reattempt the update.
Whereas, Lines mentioned in subsequent paragraph says that the retry_on_conflict will ensure us to control the data loss.
Like the index API, the update API adopts a last-write-wins approach by default, but it also accepts a version parameter that allows you to use optimistic concurrency control to specify which version of the document you intend to update.
My simple questions are
- Whether the retry_on_conflict will update the version before reattempting the update? If not then how multiple retries will help? If yes then how the order of data updates will be maintained ?
- Will there be any time gap between 2 retries b default? Is there a way to configure minimum wait time for next retry for more success ratio.
Thanks for reading my question. Please help me understand it further.