It is possible to refine how Hibernate Search interacts with Lucene through the worker configuration. The work can be executed to the Lucene directory or sent to a JMS queue for later processing. When processed to the Lucene directory, the work can be processed synchronously or asynchronously to the transaction commit.
You can define the worker configuration using the following properties
Table 3.2. worker configuration
| Property | Description |
hibernate.search.worker.backend |
Out of the box support for the Apache Lucene back end and
the JMS back end. Default to lucene. Supports
also jms.
|
hibernate.search.worker.execution |
Supports synchronous and asynchronous execution. Default
to async.
|
hibernate.search.worker.thread_pool.size |
Defines the number of threads in the pool. useful only for asynchronous execution. Default 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. |
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. |