This is similar to

Supose we have those entities:

Detail (with an ID and a description)
Master (with an ID, a description and a collection of Details)

If we write this JPQL: "SELECT master FROM Master master JOIN master.details details WHERE details.description=:description" and pass a value to ":description", we have as a result some instances of Master that, will have all details that belong to master. This is correct and expected!

If we now write this JPQL in another session: "SELECT master FROM Master master JOIN FETCH master.details details WHERE details.description=:description" and pass a value to ":description", we have as a result some instances of Master that, despite having multiple details into the database, will have only the details that matches the WHERE clause. This is not correct since the condition should only filter the masters returned but not the details!

Now, if we write a different JPQL: "SELECT master FROM Master master JOIN FETCH master.details WHERE master.id=:id" and use as ":id" the primary key of the master we got from the previous query, the instance of Master returned by Hibernate will have only the details it had in the first query, despite the fact that the second query doesn't filter details at all.

For this bug to happen we must use the same entity manager for both queries. If we create another entity manager the bug doesn't happen and also if we call "EntityManager.clear()" before the second query all details are returned, meaning probably the bug is in how Hibernate stores entities in the first level cache.

TEST-CASE

https://github.com/Dancovich/hibernate-fetch-test/tree/master/hibernate-fetch-test

This is a simple Maven project stored at github with a JUnit test that shows the issue. It is a simple project with only hibernate-entitymanager, hsqldb and junit as dependencies. The test class is "MasterDAOTest".