Accessing EntityManager prevents loading of lazy entities

[samodadela]

Describe the bug

Entity A has OneToOne to entity B, which has OneToMany to entity C. Iterating through all A's, B's and all C's.
(see attached project below)

    @Test
    @DataSet(value = "org/repro/ReproTest.yml")
    @Transactional // this annotation is required to reproduce the problem
    public void reproducer_SanityCheck() {
        // we have one A, with one B, with one C
        List<A> aList = A.listAll();
        assertThat(aList.size()).isEqualTo(1);

        A a = aList.get(0);
        B b = a.getB();
        assertThat(b).isNotNull();

        int numBs = b.getCList().size();
        assertThat(numBs).isEqualTo(1);
    }

    @Test
    @DataSet(value = "org/repro/ReproTest.yml")
    @Transactional // this annotation is required to reproduce the problem
    public void reproducer_Case1() {
        List<A> aList = A.listAll();
        assertThat(aList.size()).isEqualTo(1);

        A a = aList.get(0);
        B b = a.getB();
        assertThat(b).isNotNull();

        // after we do a listAll() on UX...
        List<UX> list = UX.listAll();

        // ... it seems as if B does not have any C
        int numCs = b.getCList().size();
        System.out.println("numBs: " + numCs);
        assertThat(numCs).isEqualTo(1);
    }

Expected behavior

reproducer_Case1() should pass.

Entities should be retrieved/listed like this:
A1, B1, C1

Actual behavior

... but this happens:
reproducer_Case1() fails... like C1 does not exist:
A1, B1, (access EM here), [C1 dissapears]

To Reproduce

See attached project with test case. Run tests in ReproTest.

Environment (please complete the following information):

Output of uname -a or ver

Linux a 5.11.10-1-MANJARO #1 SMP PREEMPT Thu Mar 25 17:14:55 UTC 2021 x86_64 GNU/Linux

Output of java -version

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

Quarkus version or git rev

1.13.1.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.6.3 (NON-CANONICAL_2019-11-27T20:26:29Z_root)
Maven home: /opt/maven
Java version: 11, vendor: Oracle Corporation, runtime: /opt/openjdk-11
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.11.10-1-manjaro", arch: "amd64", family: "unix"

Additional context

If the Transactional annotation is removed, the tests pass. But I need Transactional.
It seems that it does not matter if accessing EM is done through Panache or through EM directly (test reproducer_Case3_NoPanache()).
In certain cases (in the original source code within the real project) listing specific entities causes the problem, while listing entities of other types does not. At first I thought that the entities need a relation to B, but it seems that is not the case. That's why there are two similar test: one with entity UX (UnrelatedX) and one with RX (RelatedX)... does not matter in this setup, though.
The problem happened first in a REST resource.. I managed to create a test case from it.

The only 'workaround' I found is to 'pre-load' all B's before doing the listAll().. but this will cause other problems.

Use this project to reproduce:
repro-case-no-panache.zip

[quarkus-bot]

/cc @FroMage, @loicmathieu

[FroMage]

Would you mind trying to rewrite your example without the Panache APIs? In plain JPA/Hibernate-ORM? That will help us figure out if this is a pure-ORM issue or in the Panache layer.

[samodadela]

@FroMage I replaced the previous example with the one without Panache:

• modified the base entity to use Hibernate only
• modified tests to use EM
• replaced dependency quarkus-hibernate-orm-panache with quarkus-hibernate-orm

See repro-case-no-panache.zip in post above. It seems Panache has nothing to do with the problem.

[FroMage]

OK thanks a lot. Perhaps @yrodiere or @Sanne can take a look?

[yrodiere]

@dreab8 This seems very similar to the problem you are currently working on. Maybe it's the same problem? Otherwise just tell me, and I'll have a closer look.

[dreab8]

I managed to reproduce it in Hibernate and the fix for https://hibernate.atlassian.net/browse/HHH-14549 should resolve this issue