Package org.hibernate.search.mapper.orm.coordination

Class CoordinationStrategyNames

  • public final class CoordinationStrategyNames
extends Object

    • Field Summary

      Fields 
      Modifier and Type Field Description
      static String DATABASE_POLLING
      Database polling: one or multiple application nodes exist, and they coordinate with each other by pushing data to additional tables in the database and polling these tables.
      static String NONE
      No coordination: only one application node exists, or multiple application nodes exist, but they do not coordinate with each other, performing indexing and search requests independently.

    • Field Detail

      • NONE

        public static final String NONE
        No coordination: only one application node exists, or multiple application nodes exist, but they do not coordinate with each other, performing indexing and search requests independently.

        Warning: If you want more than one node, even with this strategy, you must use a backend that can share its data across multiple nodes; at the moment the Lucene backend cannot, and only the Elasticsearch backend can.

        Compared to actual coordination strategies, this strategy has the advantage of enabling synchronous automatic indexing, though performance may take a hit with the most strict settings (see AutomaticIndexingSynchronizationStrategyNames).

        However, in rare cases where the same document involving @IndexedEmbedded is changed by two concurrent transactions, or where backend indexing requests fail due to I/O errors, automatic indexing with this strategy may lead to out-of sync indexes. See this section of the reference documentation for more information.

        See Also:
        Constant Field Values

      • DATABASE_POLLING

        public static final String DATABASE_POLLING
        Database polling: one or multiple application nodes exist, and they coordinate with each other by pushing data to additional tables in the database and polling these tables.

        Compared to the NONE strategy, this strategy has the advantage of being immune to limitations that could lead to out-of-sync indexes, at the cost of requiring all automatic indexing to be asynchronous.

        Compared to other multi-node strategies (to be implemented), this strategy has the advantage of not requiring any additional infrastructure, since it relies exclusively on the database.

        See Also:
        Constant Field Values