Hibernate Search consists of an indexing component and an index search component. Both are backed by Apache Lucene.
Each time an entity is inserted, updated or removed in/from the database, Hibernate Search keeps track of this event (through the Hibernate event system) and schedules an index update. All the index updates are handled without you having to use the Apache Lucene APIs (see Section 3.7, “Enabling Hibernate Search and automatic indexing”).
To interact with Apache Lucene indexes, Hibernate Search has the
notion of DirectoryProviders. A directory provider
will manage a given Lucene Directory type. You can
configure directory providers to adjust the directory target (see Section 3.1, “Directory configuration”).
Hibernate Search uses the Lucene index to search an entity and
return a list of managed entities saving you the tedious object to Lucene
document mapping. The same persistence context is shared between Hibernate
and Hibernate Search. As a matter of fact, the
FullTextSession is built on top of the Hibernate
Session. so that the application code can use the unified
org.hibernate.Query or
javax.persistence.Query APIs exactly the way a HQL,
JPA-QL or native queries would do.
To be more efficient, Hibernate Search batches the write interactions with the Lucene index. There is currently two types of batching depending on the expected scope. Outside a transaction, the index update operation is executed right after the actual database operation. This scope is really a no scoping setup and no batching is performed. However, it is recommended - for both your database and Hibernate Search - to execute your operation in a transaction be it JDBC or JTA. When in a transaction, the index update operation is scheduled for the transaction commit phase and discarded in case of transaction rollback. The batching scope is the transaction. There are two immediate benefits:
Performance: Lucene indexing works better when operation are executed in batch.
ACIDity: The work executed has the same scoping as the one executed by the database transaction and is executed if and only if the transaction is committed. This is not ACID in the strict sense of it, but ACID behavior is rarely useful for full text search indexes since they can be rebuilt from the source at any time.
You can think of those two scopes (no scope vs transactional) as the equivalent of the (infamous) autocommit vs transactional behavior. From a performance perspective, the in transaction mode is recommended. The scoping choice is made transparently. Hibernate Search detects the presence of a transaction and adjust the scoping.