Support multiple persistence units for Hibernate Reactive

Describe the bug

In my test application.yaml I have configuration like below:

datasource:
  first:
    devservices:
      enabled: true
      image-name: mysql/mysql-server:8.0.21
    db-kind: mysql
  second:
    devservices:
      enabled: true
      image-name: mysql/mysql-server:8.0.21
    db-kind: mysql
hibernate-orm:
  first:
    datasource: first
    packages: com.db.model.first
    sql-load-script: import-first.sql
    database:
      generation: drop-and-create
  second:
    datasource: second
    packages: com.db.model.second
    sql-load-script: import-second.sql
    database:
      generation: drop-and-create

When I’am running tests I see warning message in console: WARN: Skipping registration of ReactiveSessionFactoryProducer and ReactiveSessionProducer because exactly one persistence unit is required for their registration

And after that test failed with: java.lang.NullPointerException: Cannot invoke "org.hibernate.reactive.mutiny.Mutiny$Session.createQuery(String)" because "em" is null

Expected behavior

Two persistent reactive units should be initialized properly.

Actual behavior

Non of reactive persistent units was initialized.

How to Reproduce?

No response

Output of uname -a or ver

Linux 5.13.0-20-generic #20-Ubuntu SMP Fri Oct 15 14:21:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

16.0.2

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.4.0.Final

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

Apache Maven 3.6.2

Additional information

No response

[Sanne]

Hi. Why isn’t multiple persistence units supported for Hibernate Reactive? The original hibernate reactive seems to support multiple persistence unit. What’s the concern about this?

There’s no instrinsic limitation, as you noticed Hibernate Reactive upstream can deal with multiple persistence units and we do plan to eventually support this in Quarkus as well.

But currently the Hibernate Reactive extension for Quarkus is in a problematic shape: it’s highly coupled to the core of the Hibernate ORM blocking extension, and the presence of it actually taints the state of the blocking ORM instances. It needs to be rewritten with a more flexible design.

But we’re aiming to support Hibernate ORM 6 first, and in terms of project steering it’s not a good idea to have these big initiatives working in parallel; since we know Hibernate Reactive also needs substantial changes to make itself ready for ORM6, I feel that re-implementing the Hibernate Reactive extension for Quarkus is better deferred to when such other tasks have been done.

This is the order in which I expect us to make progress:

1. Quarkus moves to Jakarta API (this is being worked on)
2. Hibernate Reactive moves to Hibernate ORM 6 (this is being worked on)
3. both the Hibernate ORM and Hibernate Reactive extensions need to be rewritten to support ORM6 - and that’s a good time to better model the proper coupling

Since there’s already big changes being made in parallel across all projects, it would be problematic to start the refactoring of the Hibernate Reactive extension in parallel as well. Not least because it’s the same people working on these points, so it’s not like we’d finish faster 😃

And I’d like to know the reason why persistence.xml is not supported for Hibernate Reactive.

The persistence.xml support for Hibernate ORM blocking is meant as a facilittion for people who are migrating from JPA. I don’t think people who are creating a brand new application in Quarkus should use a persistence.xml, and since clearly Hibernate Reactive users aren’t - at least eaily - going to expect “copying over” an existing persistence layer, this facility isn’t very useful for an Hibernate Reactive user.

I might be wrong, I’m actually interested why you’re asking for it? How important is that for you?

[kazik666]

Any news?