This topic has not yet been written. The content below is from the topic description.
First there is a Worker. An implementation of the Worker interface is reponsible for receiving all entity changes, queuing them by context and applying them once a context ends. The most intuative context, especially in connection with ORM, is the transaction. For this reason Hibernate Search will per default use the TransactionalWorker to scope all changes per transaction. One can, however, imagine a scenario where the context depends for example on the number of entity changes or some other application (lifecycle) events. For this reason the Worker implementation is configurable as shown in Table 3.2, “Scope configuration”. Table 3.2. Scope configuration Property Description hibernate.search.worker.scope The fully qualifed class name of the Worker implementation to use. If this property is not set, empty or transaction the default TransactionalWorker is used. hibernate.search.worker.* All configuration properties prefixed with hibernate.search.worker are passed to the Worker during initialization. This allows adding custom, worker specific parameters. hibernate.search.worker.batch_size Defines the maximum number of indexing operation batched per context. Once the limit is reached indexing will be triggered even though the context has not ended yet. This property only works if the Worker implementation delegates the queued work to BatchedQueueingProcessor (which is what the TransactionalWorker does) Once a context ends it is time to prepare and apply the index changes. This can be done synchronously or asynchronously from within a new thread. Synchronous updates have the advantage that the index is at all times in sync with the databases. Asynchronous updates, on the other hand, can help to minimize the user response time. The drawback is potential discrepancies between database and index states. Lets look at the configuration options shown in Table 3.3, “Execution configuration”. Table 3.3. Execution configuration Property Description hibernate.search.worker.execution sync: synchronous execution (default) async: asynchronous execution hibernate.search.worker.thread_pool.size Defines the number of threads in the pool for asynchronous execution. Defaults to 1. hibernate.search.worker.buffer_queue.max Defines the maximal number of work queue if the thread poll is starved. Useful only for asynchronous execution. Default to infinite. If the limit is reached, the work is done by the main thread. So far all work is done within the same Virtual Machine (VM), no matter which execution mode. The total amount of work has not changed for the single VM. Luckily there is a better approach, namely delegation. It is possible to send the indexing work to a different server by configuring hibernate.search.worker.backend - see Table 3.4, “Backend configuration”. Table 3.4. Backend configuration Property Description hibernate.search.worker.backend lucene: The default backend which runs index updates in the same VM. Also used when the property is undefined or empty. jms: JMS backend. Index updates are send to a JMS queue to be processed by an indexing master. See Table 3.5, “JMS backend configuration” for additional configuration options and Section 3.6, “JMS Master/Slave configuration” for a more detailed descripton of this setup. jgroupsMaster or jgroupsSlave: Backend using JGroups as communication layer. See Table 3.6, “JGroups backend configuration” for additional configuration options and Section 3.7, “JGroups Master/Slave configuration” for a more detailed description of this setup. blackhole: Mainly a test/developer setting which ignores all indexing work You can also specify the fully qualified name of a class implementing BackendQueueProcessorFactory. This way you can implement your own communication layer. The implementation is responsilbe for returning a Runnable instance which on execution will process the index work. Table 3.5. JMS backend configuration Property Description hibernate.search.worker.jndi.* Defines the JNDI properties to initiate the InitialContext (if needed). JNDI is only used by the JMS back end. hibernate.search.worker.jms.connection_factory Mandatory for the JMS back end. Defines the JNDI name to lookup the JMS connection factory from (/ConnectionFactory by default in JBoss AS) hibernate.search.worker.jms.queue Mandatory for the JMS back end. Defines the JNDI name to lookup the JMS queue from. The queue will be used to post work messages. Table 3.6. JGroups backend configuration Property Description hibernate.search.worker.jgroups.clusterName Optional for JGroups back end. Defines the name of JGroups channel. hibernate.search.worker.jgroups.configurationFile Optional JGroups network stack configuration. Defines the name of a JGroups configuration file, which must exist on classpath. hibernate.search.worker.jgroups.configurationXml Optional JGroups network stack configuration. Defines a String representing JGroups configuration as XML. hibernate.search.worker.jgroups.configurationString Optional JGroups network stack configuration. Provides JGroups configuration in plain text. Warning As you probably noticed, some of the shown properties are correlated which means that not all combinations of property values make sense. In fact you can end up with a non-functional configuration. This is especially true for the case that you provide your own implementations of some of the shown interfaces. Make sure to study the existing code before you write your own Worker or BackendQueueProcessorFactory implementation.