Correctly handle the flush() and clear() events in the ORM integration


In particular:

  • flushing the session should make Hibernate Search load the data from the entities and create the corresponding documents, so that a subsequent clear() won't matter. It should not lead to sending these documents to the indexes, though, because that's more the equivalent of a commit(). In short a Hibernate ORM session flush should cause a call to

  • clearing the session should make Hibernate Search forget about any changes that have not been turned into documents yet. In short a Hibernate ORM session clear should clear any state in PojoWorkPlan while preserving the state in IndexWorkPlan.

Hopefully this would solve issues such as HSEARCH-1350. We would still have a large memory consumption for large batches, so it probably wouldn't solve issues such as this one, but at least Hibernate Search would not trigger {{LazyInitializationException}}s that do nothing but confuse users.

To mitigate the memory consumption issues, maybe we could log a warning when clear() is called on the Hibernate ORM session, but there are still documents that weren't flushed to the index? That would incite people to use flushToIndex() before a clear(), or to use multiple, smaller transactions. However, I can imagine some cases where memory is not actually an issue, and the warning would thus be a false positive, because users would rather keep the process "almost transactional" by not flushing to the indexes...




Fabio Massimo Ercoli


Yoann Rodière



Suitable for new contributors


Feedback Requested



Fix versions