quarkusio/quarkus

Fine grained `reactive/blocking` property for specific persistence Units

Open

#51 205 ouverte le 24 nov. 2025

Voir sur GitHub
 (7 commentaires) (0 réactions) (0 assignés)Java (2 464 forks)batch import
area/hibernate-reactivegood first issuekind/enhancement

Métriques du dépôt

Stars
 (12 967 stars)
Métriques de merge PR
 (Merge moyen 6j 4h) (325 PRs mergées en 30 j)

Description

Description

Hibernate ORM currently exposes a global configuration property:

/**
 * Whether Hibernate ORM is working in blocking mode.
 *
 * Hibernate ORM's blocking `EntityManager`/`Session`/`SessionFactory`
 * are normally disabled by default if no JDBC datasource is found.
 * You can set this property to `false` if you want to disable them
 * despite having a JDBC datasource.
 *
 * @asciidoclet
 */
@WithDefault("true")
boolean blocking();

This property allows disabling the entire blocking Hibernate ORM stack, which is useful for users that want to use reactive persistence units exclusively.

However, because this flag applies globally, it is not possible to configure blocking vs. reactive behavior at the persistence unit (PU) level. At the moment, the only way to achieve this is indirectly, by disabling the blocking or reactive parts of the datasource itself (see https://quarkus.io/guides/datasource#jdbc-and-reactive-datasources-simultaneously and https://github.com/quarkusio/quarkus/pull/51159 for reference)

It would be significantly more flexible if this setting were available per PU. That would allow users to explicitly declare:

  • Reactive-only persistence units
  • Blocking-only persistence units
  • Or mixed applications with both, without relying on workarounds

Adding PU-level configuration (e.g., blocking = true|false and reactive=true|false inside each PU definition) would provide finer control and make these use cases first-class

Alternatively, we could have an enum BLOCKING|REACTIVE|BOTH which might be even clearer for the end user

Implementation ideas

No response

Guide contributeur