# Concurrent Updates and Index Update Questions

**URL:** <https://discourse.hibernate.org/t/concurrent-updates-and-index-update-questions/4015>\
**Category:** Hibernate Search\
**Created:** [April 13, 2020, 4:29pm UTC](https://discourse.hibernate.org/t/concurrent-updates-and-index-update-questions/4015 "2020-04-13T16:29:07Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![simi](https://avatars.discourse-cdn.com/v4/letter/s/cab0a1/32.png) [@simi](https://discourse.hibernate.org/u/simi)\
**Post date:** [April 13, 2020, 4:29pm UTC](https://discourse.hibernate.org/t/concurrent-updates-and-index-update-questions/4015/1 "2020-04-13T16:29:07Z")

</div>

I’m currently running Hibernate Search 5.10.6.Final against a 6.2 Elasticsearch instance and have had some interesting issues with the index getting out of sync by calls from our client. I’m wondering if this is a known issue.

I have 2 instances of the application running, and the client is making multiple updates to the _same_ entity from different threads. There are no optimistic concurrency exceptions in the log (the database is _correct_) but the index seems to be out of sync. A re-index “fixes” this. Is it possible (or likely) that the concurrent updates to the same entity might cause this - like the index update overwrites a change it doesn’t yet know about?

I’m having the the owner of the client attempt to serialize these calls to see if that truly is the culprit - but was wondering if perhaps this is a known issue?

Thanks for any insight!

Chris

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [April 14, 2020, 6:29am UTC](https://discourse.hibernate.org/t/concurrent-updates-and-index-update-questions/4015/2 "2020-04-14T06:29:43Z")

</div>

It is indeed a known problem. Due to how events are sourced and how data is sourced in Hibernate Search, this problem can occur if two transactions in two separate instances of the application require reindexing of a same entity at the same time: in this case, it’s possible that each instance of the application applies changes to a different part of the indexed document, and the last update will win.

Note that this problem will only occur if two transactions occur in parallel and trigger the reindexing of the same entity.

Unfortunately, that kind of problem cannot be solved with Elasticsearch’s optimistic concurrency control (\_version). There are [plans to solve this](https://hibernate.atlassian.net/browse/HSEARCH-3281) in Hibernate Search 6 by moving the part of reindexing where we extract data from entities to a separate, out-of-transaction process, so that reindexing is effectively serialized for a given entity. But that will take time, as we have other matters to address in Search 6 first.

In the meantime, yes, your options are:

- to reindex periodically to fix the few problems that will invariably occur over time. [That can be done with zero downtime](https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#backend-elasticsearch-indexlayout) in Hibernate Search 6 with Elasticsearch, with a bit of work on your side.
- or to serialize the changes affecting that problematic entity yourself, so that the problems never occur in the first place.

---

<div class="post-metadata">

**Author:** ![simi](https://avatars.discourse-cdn.com/v4/letter/s/cab0a1/32.png) [@simi](https://discourse.hibernate.org/u/simi)\
**Post date:** [April 14, 2020, 11:38am UTC](https://discourse.hibernate.org/t/concurrent-updates-and-index-update-questions/4015/3 "2020-04-14T11:38:54Z")

</div>

Thank you for the quick response. As per your comments - the client has successfully reproduced and fixed the issue by moving from parallel to serial access when performing updates. Interesting news on version 6 - thanks for the heads up.

Chris