# Elastic search optimistic concurrency control not working as expected **URL:** \ **Category:** Elasticsearch\ **Created:** [February 24, 2022, 6:43pm UTC](https://discuss.elastic.co/t/elastic-search-optimistic-concurrency-control-not-working-as-expected/298208 "2022-02-24T18:43:05Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![reddroid](https://avatars.discourse-cdn.com/v4/letter/r/a88e4f/32.png) [@reddroid](https://discuss.elastic.co/u/reddroid)\ **Post date:** [February 24, 2022, 6:43pm UTC](https://discuss.elastic.co/t/elastic-search-optimistic-concurrency-control-not-working-as-expected/298208/1 "2022-02-24T18:43:05Z")
Hi, We are using Elasticsearch version 7.16.2 with the Java Rest client to process and store documents in Elasticsearch in a Spring application . We are noticing this intermittent issue where documents with lower seq no was saved when doing an Index request for an exiting document . **Implemetation :** First we do a find to check if the document exists . If exists , we do a index request and use the seq no from the get request to do the index request to update the document with the latest info. Intermittently we are seeing this issue . **Chronology of Events:** 1. **Host 1 :** Current Document seqno : 262738316 and primaryTerm:7 . Successfully indexed to Elasticsearch and this should have been the final update . We got back the new seq no as Seq no :262738317 and primaryTerm:7 2. **Host 2:** An older event was picked for processing with seqNo:262738315,primaryTerm:7 . This should not have not have been updated but Elasticsearch indexed this document anyways and the new seqno that was returned was seqNo:262738316,primaryTerm:7 . Which is wrong . The time difference between the logs are 500ms. So , they are not happening at the same time. Also, note that we have 3 servers that are in parallel processing and updating a ES cluster of 5 nodes. Please has anyone noticed this issue ? ---
**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:** [February 24, 2022, 7:19pm UTC](https://discuss.elastic.co/t/elastic-search-optimistic-concurrency-control-not-working-as-expected/298208/2 "2022-02-24T19:19:58Z")
It sounds like your host clocks are out of sync by more than 500ms. ---
**Author:** ![reddroid](https://avatars.discourse-cdn.com/v4/letter/r/a88e4f/32.png) [@reddroid](https://discuss.elastic.co/u/reddroid)\ **Post date:** [February 24, 2022, 7:54pm UTC](https://discuss.elastic.co/t/elastic-search-optimistic-concurrency-control-not-working-as-expected/298208/3 "2022-02-24T19:54:53Z")
Not sure what you mean by that . Please can you elaborate ? ---
**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:** [February 24, 2022, 10:47pm UTC](https://discuss.elastic.co/t/elastic-search-optimistic-concurrency-control-not-working-as-expected/298208/4 "2022-02-24T22:47:35Z")
Since everything is in the same primary term it means that the sequence numbers are being assigned by a single primary, which means they are assigned in order. So the update from `262738315` to `262738316` definitely took place before the update from `262738316` to `262738317`. The usual explanation for seeing these things happen in the other order on different systems is that the timestamps on the other systems aren't accurate. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [March 24, 2022, 10:47pm UTC](https://discuss.elastic.co/t/elastic-search-optimistic-concurrency-control-not-working-as-expected/298208/5 "2022-03-24T22:47:53Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.