Thanks you for your feedback. Since this is not an issue with Hibernate, but rather with how it's used, I will close this ticket.

In order to make Hibernate Search easier to use and to reduce the impact of this problem, I opened two tickets for Hibernate Search 6:

• https://hibernate.atlassian.net/browse/HSEARCH-3303#icft=HSEARCH-3303 to document the "batching" use case and explain how it should be implemented when Hibernate Search is involved.

• https://hibernate.atlassian.net/browse/HSEARCH-3360#icft=HSEARCH-3360 to at least avoid LazyInitializationExceptions when applying the <make changes> ; flush(); clear(); <repeat> pattern. We will potentially have an OutOfMemoryException in some cases (since the index work cache will not be flushed before the end of the transaction) , but that may be easier to debug for users.

Thanks for the great documentation/comments, they were very helpful and greatly appreciated.

For now, to maintain data consistency between my entities and Hibernate Search, I will refrain from utilizing flush(), clear() or flushToIndexes() and try to batch my updates utilizing multiple transactions verses a single big transaction.

I forgot: this can also happen if you cleared your session without flushing to the indexes first. Which is also a mistake, because it effectively detaches all entities from the session, which means Hibernate Search won't be able to access lazily loaded data anymore. In the <make changes>; flush(); clear(); <repeat> pattern, you should always perform a FullTextSession.flushToIndexes() before the clear(). However, it has the side effect of making your transaction leaky, in the sense if the transaction is rolled back, the index changes will not. A safer solution is to open one transaction per batch.

See this stackoverflow answer for more information. In particular:

The first, perhaps more correct, solution, would be for you to not use a single, big transaction, but multiple smaller ones. For example create a transaction for each chunk of 200 elements. Of course this means if a chunk fails, the previous chunks will still be in the database, but in many cases this might not matter, as you can just restart from where you failed, and the index would still be in sync with the database.

Spring gives you control over transactions using transaction templates, so you can manually start a new transaction for each chunk of 200 elements, or just refactor your code to put the @Transactional annotation at the right place. [There should be similar features in Java EE, I just don't know about them out of the top of my head.]

The second solution would be for you to still use a single, big transaction, but during the transaction periodically flush your changes, both to the database (which would be able to rollback the changes later if the transaction is aborted, don't worry) and to the index (which would not be able to rollback the changes later). This means in particular that if the transaction fails, you would have to restart everything and purge the index, because it would not be in sync with the database (which rolled back the changes) anymore.

You can find an example using periodic flushing in the documentation: https://docs.jboss.org/hibernate/search/5.10/reference/en-US/html_single/#search-batchindex-flushtoindexes

If you adapt the example, your code will look more or less like this:

It seems your problem happens during PostTransactionWorkQueueSynchronization.beforeCompletion, which means proxies should still have a session.

Except... if you used entities from another session, or serialized/deserialized entities, without first attaching them explicitly to the new session. If you did that, then it's not a bug in Hibernate Search, it's just a bug in either Hibernate ORM or in your application: Hibernate Search cannot possibly detect that an entity comes from another session and decide to re-attach it to the new session for you. Even Hibernate ORM does not!

I'd recommend checking where that particular entity comes from and ensuring it is correctly attached to the session before it is added to your main (indexed) entity. If that solves the issue, then we can close this ticket.

See the section about working with detached data in the Hibernate ORM documentation.

I had a quick look at the test case template and even created my own test case though I have been unable to reproduce. In the situation I described above I am utilizing Wildfly / JEE container-managed transactions (@Transactional(value=TxType.REQUIRES_NEW)) which could be the contributing factor.

Eclipse Debug Stacktrace of LazyInitializationException -

The Wildfly instance logs -

I did some digging and it might be related to -

• http://lists.jboss.org/pipermail/hibernate-dev/2012-December/009254.html - Lazy initialization vs HSearch - Round 4

• http://lists.jboss.org/pipermail/hibernate-dev/2012-December/009283.html - Lazy initialization vs HSearch - Round 4

• https://hibernate.atlassian.net/browse/HSEARCH-1201#icft=HSEARCH-1201

• https://hibernate.atlassian.net/browse/HSEARCH-1350#icft=HSEARCH-1350

Thank you for your report.

Unfortunately, Hibernate Search 5.5 is no longer maintained as a community branch, so it won't be receiving a fix for this problem.

That being said, if a later version (5.6.x, 5.9.x or 5.10.x) is still affected, we will definitely try to apply a fix to those branches, and you can upgrade to one of those versions to benefit from the fix.

I was not able to reproduce your issue. Maybe you could try to upgrade to Hibernate Search 5.6 and see if it still affects you? See these instructions for WildFly. Just be careful about the version, 5.6.6.Final has just been released but did not hit Maven Central yet (we're experiencing sync issues), so either grab it from SourceForge or use 5.6.5.Final for now.

Also, there might be more to the problem than the configuration you showed: some corner case related to your overall mapping, some unusual entity saving pattern, ... The best way to help us reproduce your problem would be to provide a test case based on our test case template. I pushed my unsuccessful attempt to reproduce your issue to the HSEARCH-3358 branch of my fork, maybe you could iterate on that?