Hibernate caching issues with Quarkus 2.2.5.Final

Describe the bug

We have a Kafka consumer method which is annotated with @Blocking. Every time this method receives an event it executes a “list” query using entity manager like select entity from Foo entity and after that it creates a DTO for each one of the returned entities. The first time we receive an event after startup we can see the hibernate sql logs for the “list” query and every subsequent sql log for loading the @OneToMany relationships for every entity when creating the DTO. When a second event arrives we can only see the sql log for the initial “list” query. It seems that hibernate is caching the results between the two events. This happens even if the data where changed in the database between the events leading to loading old data in the DTO. Also the issue happens both in dev and prod modes.

This was working correctly with Quarkus 1.11.2.Final and the issue started when we upgraded to 2.2.5.Final. We are using quarkus-hibernate-orm, quarkus-smallrye-reactive-messaging-kafka, quarkus-jdbc-postgresql and we have no 2LC configured.

Expected behavior

The data should be loaded from the database every time.

Actual behavior

The data are cached between events.

How to Reproduce?

No response

Output of uname -a or ver

Microsoft Windows [Version 10.0.19043.1466]

Output of java -version

java version “11.0.12” 2021-07-20 LTS Java™ SE Runtime Environment 18.9 (build 11.0.12+8-LTS-237) Java HotSpot™ 64-Bit Server VM 18.9 (build 11.0.12+8-LTS-237, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.2.5.FINAL

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

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)

Additional information

No response

[mkouba]

^ In other words, it’s rather complicated 😄

[manovotn]

Do we have any time frame on this being fixed?

The cause of this issue is being discussed in https://github.com/quarkusio/quarkus/discussions/23363, so take a look there if you’re interested. In shot, the core problem is that within reactive a CDI request context is captured and “endlessly propagated” and the entity manager is @RequestScoped so it just keep returning the same instance. So this problems spans beyond just Entity Manager.

We have already discussed a possible solution/workaround and I’ll try to create a PR by tomorrow and we’ll see if that fixes more than it breaks 😉 I know there is also a fix planned on Mutiny side but I have no idea how’s that going, @cescoffier might know more.