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


#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:

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

Regards,
Niko


#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


#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.