RESTEasy Reactive vs Hibernate ORM: Are @NonBlocking endpoints safe to call blocking JPA?

In a Quarkus application that mixes RESTEasy Reactive and Hibernate ORM, the goal is to determine whether synchronous repository calls—such as PanacheRepository.save()—executed inside a @NonBlocking resource method are automatically migrated off the Vert.x event‑loop. The main constraint is that Hibernate’s JDBC interactions are inherently blocking; if they run on the event‑loop, they can stall all reactive traffic.

Quarkus dispatches @NonBlocking resource methods onto the Vert.x event‑loop, while @Blocking methods are scheduled on worker threads. However, the documentation does not explicitly state whether a blocking call made within a @NonBlocking method triggers an automatic thread migration.

Another uncertainty is the interaction with @Transactional boundaries: does the transaction’s flush occur before the resource method returns, or only at commit time? This affects visibility of persisted entities to other concurrent requests.

Given these ambiguities, the following questions remain unresolved:

• Does Quarkus guarantee that a blocking Hibernate call inside a @NonBlocking RESTEasy Reactive endpoint is automatically offloaded to a worker thread?
• Under what conditions, if any, can the Vert.x event‑loop be blocked by such a call?
• Does the @Transactional boundary ensure that flushes occur before the endpoint method completes, or only at transaction commit?