# Handling Conflicts **URL:** \ **Category:** Elasticsearch\ **Created:** [June 9, 2018, 8:48pm UTC](https://discuss.elastic.co/t/handling-conflicts/135240 "2018-06-09T20:48:04Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![panda2004](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/panda2004/32/19473_2.png) [@panda2004](https://discuss.elastic.co/u/panda2004)\ **Post date:** [June 9, 2018, 8:48pm UTC](https://discuss.elastic.co/t/handling-conflicts/135240/1 "2018-06-09T20:48:04Z")
Hey, I do know that ElasticSearch uses internally version control, for optimistic concurrency control. It guarantees that only one update is processed at once to a document. However, what happens when processing multiple updates to the same document in one bulk? Or even worse - multiple updates to the same document from different bulks? In our system, we use partial updates. In case of adding nested documents or incremental update some property - it's okay. I don't care which nested document is added before the other, and incremental value update doesn't care either. But, in case of an update which overrides some properties the order DOES matter, because the last write wins. In this illustration, I have 3 different groups (gray, green, orange) in the documents, each partially updates. While concurrent add and incremental updates are okay (no conflicts might occur), concurrent override/replace requests are dangerous. ![Update](https://us1.discourse-cdn.com/elastic/original/3X/c/8/c8702820c7e6dd344e16b029cfc382419ca1de4d.png) A solution for that is using some kind of time checking, like mentioned [here](https://discuss.elastic.co/t/conditional-update-to-the-document/64964/18). Meaning, making the update only if it is the newer: ``` POST /Shows/Show/332/_update { "scripted_upsert": true, "script" : { "inline": "if (ctx._source.last_update_time>= params.timestamp) { ctx.op = 'none' } else { ctx._source = params.document }", "lang": "painless", "params": { "document": { "timestamp": 112255 } } }, "upsert": { "timestamp": 33333 } } ``` Another solution, might be making sure only one bulk is handling the gray group updates. Hopefully, somehow updates in the same group are done according to their order. Didn't find any related information about it in ElasticSearch documentation. I did see mentioning this in [this](https://discuss.elastic.co/t/order-of--bulk-request-operations/98124) discussion. What do you think? Is It an appropriate solution? ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [June 10, 2018, 3:10am UTC](https://discuss.elastic.co/t/handling-conflicts/135240/2 "2018-06-10T03:10:52Z")
May be interesting to read: > **[Elasticsearch Versioning Support | Elastic](https://www.elastic.co/blog/elasticsearch-versioning-support)** > > Elasticsearch Versioning Support One of the key principles behind Elasticsearch is to allow you to make the most out of your data. Historically, search was a read-only enterprise where a search engine... And - [https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs-index\_.html#index-versioning](https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs-index_.html#index-versioning) - [https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs-bulk.html#bulk-versioning](https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs-bulk.html#bulk-versioning) ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [June 10, 2018, 5:46am UTC](https://discuss.elastic.co/t/handling-conflicts/135240/3 "2018-06-10T05:46:34Z")
Apart from concurrency and correctness, be aware that very frequent updates to documents can cause poor performance. If a document that have not yet been written to a segment is updated, this will cause a refresh to occur. You could therefore end up with lots of very small refreshes, which is inefficient. ---
**Author:** ![panda2004](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/panda2004/32/19473_2.png) [@panda2004](https://discuss.elastic.co/u/panda2004)\ **Post date:** [June 11, 2018, 5:56am UTC](https://discuss.elastic.co/t/handling-conflicts/135240/4 "2018-06-11T05:56:14Z")
Hey, thanks. Actually read all of that posts before publishing my post, thanks. All of them mention the problem of concurrency and the version control mechanism, but don't answer my question directly. In the [bulk](https://www.elastic.co/guide/en/elasticsearch/reference/6.2/docs-bulk.html#bulk-versioning) post, I can see that the versions of the document grow according to the order of the requests. But I don't understand if it is guaranteed or it just for demonstration purposes. ---
**Author:** ![panda2004](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/panda2004/32/19473_2.png) [@panda2004](https://discuss.elastic.co/u/panda2004)\ **Post date:** [June 11, 2018, 6:02am UTC](https://discuss.elastic.co/t/handling-conflicts/135240/5 "2018-06-11T06:02:12Z")
Thanks for the response and concerns. Most of the times, we are talking about 5 to 15 updates, and the maximum number I have ever seen for version number was 30 at max for a single document. Some of the updates occur right after the other (seconds delay), and some of them might occur after hours or days. The override is done automatically by machine, and might be the first 5 updates. But other partial updates are done by customers and usually no more than 3 customers work on the same document. After considering those numbers, do you think it is more appropriate? Until now we haven't suffered from performance issues while indexing / updating our documents. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 9, 2018, 6:02am UTC](https://discuss.elastic.co/t/handling-conflicts/135240/6 "2018-07-09T06:02:18Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.