Interface ElasticsearchSerialWorkOrchestrator
- All Known Implementing Classes:
ElasticsearchBatchingWorkOrchestrator
Serial orchestrators are best used as index-scoped orchestrators, when many works are submitted from different threads: they allow easy implementation of a reasonably safe (though imperfect) concurrency control by expecting the most recent work to hold the most recent data to be indexed.
With a serial orchestrator:
- Works are executed in the order they were submitted in.
- Two submitted works from the may be sent together in a single bulk request, but only if all the works between them are bulked too.
- The application will wait for already-submitted works to finish when shutting down.
Note that while serial orchestrators preserve ordering as best they can, they lead to a lesser throughput and can only guarantee ordering within a single JVM. When multiple JVMs with multiple instances of Hibernate Search target the same index, the relative order of indexing works might end up being different from the relative order of the database changes that triggered indexing, eventually leading to out-of-sync indexes.
-
Method Summary
Modifier and TypeMethodDescriptiondefault <T> voidsubmit(CompletableFuture<T> future, IndexingWork<T> work, OperationSubmitter operationSubmitter) voidsubmit(org.hibernate.search.backend.elasticsearch.orchestration.impl.ElasticsearchBatchedWork<?> work, OperationSubmitter operationSubmitter) default <T> CompletableFuture<T>submit(IndexingWork<T> work, OperationSubmitter operationSubmitter)
-
Method Details
-
submit
default <T> CompletableFuture<T> submit(IndexingWork<T> work, OperationSubmitter operationSubmitter) -
submit
default <T> void submit(CompletableFuture<T> future, IndexingWork<T> work, OperationSubmitter operationSubmitter) -
submit
void submit(org.hibernate.search.backend.elasticsearch.orchestration.impl.ElasticsearchBatchedWork<?> work, OperationSubmitter operationSubmitter)
-