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