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

Description

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 org.hibernate.search.mapper.pojo.mapping.PojoWorkPlan#prepare.

  • 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...

Environment

None

Status

Assignee

Fabio Massimo Ercoli

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Feedback Requested

None

Components

Fix versions

Priority

Major