Assertion error in org.hibernate.engine.internal.BatchFetchQueueHelper

Hibernate ORM
1

Hi there,

using Hibernate 5.2.16, I’m encountering an assertion error in org.hibernate.engine.internal.BatchFetchQueueHelper#removeNotFoundBatchLoadableEntityKeys

assert idSet.size() == ids.length - results.size();

a) when bytecode enhancement is disabled
b) in Hibernate Search with enabled bytecode enhancement.

Is there a usual suspect I can track down this?
While debugging the assertion, I can see this:

image

As results show ambigous results, might this be related to an incorrect hashcode/equals implementation?

Regards,
Niko

1 Like
2

From the image, it looks like the results ArrayList have a duplicated User@14158 while the ids are deduplicated.

Try to provide a replicating test case.

3

Providing a test case will be quite tricky. But I’ve just found out that this only happens when AvailableSettings.DEFAULT_BATCH_FETCH_SIZE is set. Not using batch fetches does not cause this issue.

4

Without a test case that proves the issue, it’s not clear what exactly is not working properly and requires a fix.

5

Of course. I will tackle this issue ASAP.

6

In Hibernate 5.3.0, the error thrown is slightly different as bootstrapping fails.

See https://hibernate.atlassian.net/browse/HHH-12594

1 Like
7

Maybe the error message has changed due to working on this issue for improving performance

8

The difference is now that bootstrapping fails, before the issue occured after the bootstrapping process. But anyhow, a test case exists for this one, so this can be further investigated now.

9

I’m going to integrate the test case and see if I can fix the issue.

10

Hi, i have the same problems, at least in one case I could solve it by changing an Fetch.EAGER with implicit JOIN to an Fetch.EAGER with explicit FetchMode.SELECT, which looks like an cartesian product problem to me.

Problem Version: 5.2.17.Final
No Problem before with 5.2.1.Final

I retested Versions, Problems start with 5.2.10.Final, before that I do not have this error.

11

FetchType.EAGER is almost always a bad idea.

12

Well OK… but no reason to break existing behaviour.

13

That’s a bug indeed, but if you stumbled on it, you might have more issues due to using EAGER fetching than the one caused by this regression.

14

Vlad, thanks for answering, i just wanted to provide some input on the topic.
I will never use EAGER anymore, i swear to the holy god of relationality :wink:

15

That’s the spirit! Remember that the @ManyToOne and @OneToOne associations are EAGER by default, so keep that in mind.

16

Using Hibernate 5.3.2, I’m again encountering the original error message when “hibernate.default_batch_fetch_size” is set with bytecode enhanced entities. I will try to provide a test case ASAP.

17

You should create a new Jira issue for 5.3.2 then. Thanks.

18

I’m still struggling to create a test case for this due to lack of time, but https://hibernate.atlassian.net/browse/HHH-12835 now has solved the issue.