Elasticsearch/OpenSearch offer support for optimistic concurrency control through versioning: (not to be confused with )
When using Hibernate Search in Standalone mode, it could be useful to have some form of @DocumentVersion.
For example:
When using Elasticsearch/OpenSearch as a primary datastore, one could rely on auto-incrementing versions, and use a @VersionProjection (to be added) to retrieve the version before every update, therefore taking advantage of optimistic concurrency control.
When using Elasticsearch/OpenSearch as a secondary datastore whose data is derived from another document datastore (e.g. MongoDB), one could rely on that other datastore’s own versioning mechanism, pushing the version explicitly on each update.
It’s less clear whether mapping Hibernate ORM’s own @Version to Elasticsearch/OpenSearch’s version actually is useful, because the “version” of indexed documents relates to more than just the root entity (there may be @IndexedEmbedded involved, and embedded entities have their own version). But it’s less critical when using Hibernate ORM, since in that case one can use coordination with outbox polling, which achieves better concurrency control through sharding (there are never two nodes updating the same document at the same time).
Support for concurrency control in Lucene may be challenging, so we may want to leave that out of scope for now.
Elasticsearch/OpenSearch offer support for optimistic concurrency control through versioning: (not to be confused with )
When using Hibernate Search in Standalone mode, it could be useful to have some form of
@DocumentVersion.For example:
When using Elasticsearch/OpenSearch as a primary datastore, one could rely on auto-incrementing versions, and use a
@VersionProjection(to be added) to retrieve the version before every update, therefore taking advantage of optimistic concurrency control.When using Elasticsearch/OpenSearch as a secondary datastore whose data is derived from another document datastore (e.g. MongoDB), one could rely on that other datastore’s own versioning mechanism, pushing the version explicitly on each update.
It’s less clear whether mapping Hibernate ORM’s own
@Versionto Elasticsearch/OpenSearch’s version actually is useful, because the “version” of indexed documents relates to more than just the root entity (there may be@IndexedEmbeddedinvolved, and embedded entities have their own version). But it’s less critical when using Hibernate ORM, since in that case one can use coordination with outbox polling, which achieves better concurrency control through sharding (there are never two nodes updating the same document at the same time).Support for concurrency control in Lucene may be challenging, so we may want to leave that out of scope for now.