See in particular org.hibernate.search.mapper.orm.impl.HibernateSearchContextService#enlistInTransaction.

Note that this ticket only makes sense if we manage to implement a transactional backend, which probably only makes sense for clustered backends to be reintroduced as part of . So we probably don't need to worry about this use case until we start working on .

At the very least we should restore a setting similar to hibernate.search.worker.enlist_in_transaction in Hibernate Search 5.

We might want to reconsider the approach to enlist in the transaction depending on the involved indexes. Some indexes being more critical than others, users might want to use a transactional backend for some, and a non-transactional, more scalable backend for others.

In that case, to make the mapper layer benefit from potential performance gains, we should probably use two work plans: one to be executed within the transaction, for entities mapped to transactional backends/indexes, and the other to be prepared within the transaction, but executed after commit, for entities mapped to non-transactional backends/indexes.

As long as the two work plans target strictly separate indexes, I don't see many potential problems... ?