Lazy @OneToMany is not very lazy

[plevart]

Hi,

There's been some discussion (#17291) about the laziness of @onetomany associations in regards to how they are implemented when Hibernate is used with Quarkus so I wanted to ask whether there are some specifics in this case vs. when Hibernate is used without Quarkus. It might be that @onetomany associations behaved differently in Hibernate 5.3 and before and that this new behavior is entirely Hibernate's fault (using Hibernate 5.6.10 with Quarkus 2.11.2).
What I'm curious about is whether Hibernate.isInitialized(entity) == true guarantees that any method called upon entity will not trigger any lazy loading. This currently does not hold for getters returning collections annotated with @OneToMany(fetch = FetchType.LAZY). I was expecting that I would get a proxy collection which would probably not be loaded but obtaining that collection would not trigger any Hibernate Session interaction. Here's a part of stacktrace where this happens:

Caused by: org.hibernate.LazyInitializationException: Unable to perform requested lazy initialization [eu.otlm.ferengi.hibernate.model.Tower$E.spanB] - no session and settings disallow loading outside the Session
        at org.hibernate.bytecode.enhance.spi.interceptor.EnhancementHelper.throwLazyInitializationException(EnhancementHelper.java:275)
        at org.hibernate.bytecode.enhance.spi.interceptor.EnhancementHelper.performWork(EnhancementHelper.java:165)
        at org.hibernate.bytecode.enhance.spi.interceptor.LazyAttributeLoadingInterceptor.loadAttribute(LazyAttributeLoadingInterceptor.java:80)
        at org.hibernate.bytecode.enhance.spi.interceptor.LazyAttributeLoadingInterceptor.fetchAttribute(LazyAttributeLoadingInterceptor.java:76)
        at org.hibernate.bytecode.enhance.spi.interceptor.LazyAttributeLoadingInterceptor.handleRead(LazyAttributeLoadingInterceptor.java:57)
        at org.hibernate.bytecode.enhance.spi.interceptor.AbstractInterceptor.readObject(AbstractInterceptor.java:153)
        at eu.otlm.ferengi.hibernate.model.Tower$E.$$_hibernate_read_spanB(Tower.java)
        at eu.otlm.ferengi.hibernate.model.Tower$E.getSpanB(Tower.java:64)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

...and this is the mapping used on the getter:

        @Override
        @OneToMany(targetEntity = Span.E.class, mappedBy = "towerB", fetch = FetchType.LAZY)
        public Set<Span> getSpanB() {
            return spanB;
        }

Philosophically, why should this be different from say @ManyToOne(fetch = FetchType.LAZY) association, where a lazy proxy is normally returned without any requirement that Hibernate Session is still active. It looks like @OneToMany(fetch = FetchType.LAZY) is not very lazy at all.

[yrodiere]

I was expecting that I would get a proxy collection which would probably not be loaded but obtaining that collection would not trigger any Hibernate Session interaction

That's what I'd expect as well... However, I can't help but wonder: why does it matter in your case, since that collection will throw an exception as soon as you try to do anything with it?

[yrodiere]

Thanks a lot! One of two, not bad when we weren't even trying to fix those :)

I'll update my PR to mention #4644.

[fabrii]

You're welcome. I would really appreciate if you can take a little look on #22204 whenever possible, or point me in the right direction (if it is something I can fix).
You already fixed one that was similar #17291

Thank you!

[yrodiere]

I've added #22204 it to my to-do list; don't hold your breath though, as that list is unfortunately quite long. I also don't have much experience with Envers; your best bet would be @Naros... who seems busy as well :)

As to pointing you in the right direction... I doubt this is a Quarkus bug, it's more likely a bug in Hibernate ORM itself. If you manage to reproduce it in a new test in the Hibernate ORM codebase, you will be in a better position to investigate what's going on exactly.

From the (quick) look I had, it seems Envers is using its own set of lazy collection (e.g. org.hibernate.envers.internal.entities.mapper.relation.lazy.proxy.ListProxy), and those are not handled by Hibernate.isInitialized, which sees them as initialized collections, always. So that's a good news: laziness works properly, it's just Hibernate.isInitialized reporting the wrong information.

If you know Hibernate.isInitialized used to work on Envers collections in an older version of ORM, you might be able to run the same test in that version, debug isInitialized, and take inspiration from the code path in that version. Otherwise, you'll probably need to innovate... Maybe add a interface LazyInitializable that PersistentCollection would extend, and which would only declare the method wasInitialized, then implement that interface in Envers collections?

[fabrii]

I'll have a look this weekend! Thanks

[fabrii]

I ran the Hibernate.isInitialized test in the 5.6, 5.2 and 5.0 branches. It is not working in any of those. As you said, Envers uses a ListProxy class instead of PersistentCollection. The ListProxy class does not have any method to check if it is initialized or not. Your LazyInitializable interface proposal may be the way to go. I'll update the issue with this info.

[yrodiere]

#27666 should fix this. Thanks to you for reaching out, and thanks to @beikov for setting me on the right path!