# Concurrency control of Update **URL:** \ **Category:** Elasticsearch\ **Created:** [June 1, 2019, 8:11am UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816 "2019-06-01T08:11:47Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![shayantabrizi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shayantabrizi/32/45398_2.png) [@shayantabrizi](https://discuss.elastic.co/u/shayantabrizi)\ **Post date:** [June 1, 2019, 8:11am UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816/1 "2019-06-01T08:11:47Z")
I'm confused about the concurrency control of update. It seems that update does check for conflicts: > In between the get and indexing phases of the update, it is possible that another process might have already updated the same document. By default, the update will fail with a version conflict exception. Also there are two parameters `if_seq_no` and `if_primary_term` related to concurrency control. According to the documentation, maybe, the default check of update uses versioning while `if_seq_no` and `if_primary_term` can be provided manually. However, according to [here](https://github.com/elastic/elasticsearch/issues/19269#issuecomment-488598561) maybe checking according to versioning is not reliable and seq\_no and primary\_term must be used instead. Can I rely on update's own checking for conflicts? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [June 1, 2019, 9:08am UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816/2 "2019-06-01T09:08:00Z")
> [@shayantabrizi](#): > > Can I rely on update's own checking for conflicts? Yes. Internally the update is using the reliable `if_seq_no` and `if_primary_term` mechanism to detect conflicting updates. ---
**Author:** ![shayantabrizi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shayantabrizi/32/45398_2.png) [@shayantabrizi](https://discuss.elastic.co/u/shayantabrizi)\ **Post date:** [June 1, 2019, 11:16am UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816/3 "2019-06-01T11:16:09Z")
So when should we manually use `if_seq_no` and `if_primary_term`? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [June 1, 2019, 11:29am UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816/4 "2019-06-01T11:29:07Z")
I'm not sure I'm understanding the question. You should use the explicit concurrency control mechanism (i.e. `if_seq_no` and `if_primary_term`) if you want explicit control over the behaviour of concurrent operations. ---
**Author:** ![shayantabrizi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shayantabrizi/32/45398_2.png) [@shayantabrizi](https://discuss.elastic.co/u/shayantabrizi)\ **Post date:** [June 1, 2019, 11:56am UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816/5 "2019-06-01T11:56:19Z")
It seems that Update checks for conflicts by default, without mentioning `if_seq_no` and `if_primary_term` and you said: > Yes. Internally the update is using the reliable `if_seq_no` and `if_primary_term` mechanism to detect conflicting updates. If it uses `if_seq_no` and `if_primary_term` internally by default, why should someone use `if_seq_no` and `if_primary_term` parameters explicitly? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [June 1, 2019, 1:09pm UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816/6 "2019-06-01T13:09:29Z")
> [@shayantabrizi](#): > > why should someone use `if_seq_no` and `if_primary_term` parameters explicitly? If they want the same behaviour for some other reason. There's only so much you can do with a scripted update. For instance I don't know that you can look things up in an external system during an update, so if you wanted to update a document like this you wouldn't be able to do it in a single update. Instead you would need to get the document, calculate the update outside of Elasticsearch, and then insert the updated document back into Elasticsearch using this explicit concurrency control mechanism. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 29, 2019, 1:09pm UTC](https://discuss.elastic.co/t/concurrency-control-of-update/183816/7 "2019-06-29T13:09:30Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.