Elastic partial update retry_on_conflict and database write lock details

1 update of the database in the process of modifying this data (this process refers to the database to perform the update to the transaction commit process) for this data with a write lock, blocking other transactions on the lock data modification, the request after a modified transaction thread blocked until the completion of the previous transaction, so against this number According to the 2 changes are one to come. So the database update T1 set a = a+1;  Such an operation does not result in the loss of a data because the previous transaction was executed when the data was committed after a transaction was blocked. However, if A=1 is queried first, then A = 1 (this 1 is the query to a) +1, such an operation will lose a, because a two transaction query a may be modified.

2, es all modified, if not with the version of the time, directly replace the original document, no query process. Multi-threaded operation, does not distinguish between the order of execution. But when you take version, version indicates the order. The first execution succeeds, then the illegal is discarded (throws an exception).

3, ES Partial modification, when the modification request to ES, ES in the internal query the principle of the document, and then perform, part of the update, note that this is ES does not prevent other threads to modify this data, perhaps this ES internal query has multiple (this stage is called Retrie   VE), retrieve complete record this is version, and the new data passed to create a new document, and then change the old document to false delete (this process is called reindex), this time will modify the set Version=version and Version = version, if another thread does the same thing and slows down a little bit, rebuilding the index will be an exception. This is when ES repeatedly retrieves and reconstructs the index, knowing that normal completion or retry attempts are greater than retry_on_conflict throws an exception.

Es the principle of the bar on the document

Summary: the database rejects the second transaction to modify data that has been modified but not committed (the transaction is not committed). The full update of ES will not have the process of automatic retrieval, direct replacement, and concurrency can be controlled through version. Some updates are automatically retrieved, and concurrent modification conflicts are retrieved, with version and then re-building the index

An exception is thrown after retrying retry_on_conflict, and can also be controlled by version (retry_on_conflict default 0 is equivalent to automatically taking version, but not equivalent, because the time of version reading is different , some situations may be different results, the main Ken writing and business scenarios such as a = A+1 will not affect, but a = to have an impact, you can carefully understand, very interesting).

Elastic partial update retry_on_conflict and database write lock details