HR000069: Detected use of the reactive Session from a different Thread

hibernate / hibernate-reactive

A reactive API for Hibernate ORM, supporting non-blocking database drivers and a reactive style of interaction with the database.

https://hibernate.org/reactive

Apache License 2.0

425 stars 89 forks source link

HR000069: Detected use of the reactive Session from a different Thread #1667

Open dstepanov opened 1 year ago

dstepanov commented 1 year ago

In Micronaut Data we have a reported issue with Hibernate Reactive and context switching. https://github.com/micronaut-projects/micronaut-data/issues/2165

There can be the following use-case:

Open session or TX (Hibernate Reactive opens a sessing and remembers thread ID X)
Retrieve something
Context switch by accessing another DB or HTTP etc.
- Thread with ID X is no longer needed; it can be reused for another DB work of Hibernate Reactive.
The operation is done and Hibernate Reactive can continue work in the context of the session/tx
Here, close session/tx will fail because the thread ID is not equal to X. This doesn't make sense to me because thread X can be used for another operation. The check should only validate that the thread is part of the event loop of the vertx.

Please help me to understand the problem.

uPagge commented 7 months ago

Any news on this problem? It's making it very difficult for us to do our jobs. What are the workarounds to this problem now?

Froidoh commented 4 months ago

I would be enough if one could manually close the session for me right now.

I am having a non-blocking working service that uses the DB. Works like a charm.

New requirement: Same REST call for clients: In a special case I need to call another blocking HTTP service in case we don't have the information in our Database... either I get warnings that I am blocking in a reactive context or I get the infamous HR000069: Detected use of the reactive Session from a different Thread

If I could just close the session and avoid HR000069 that way and offload to Infrastructure.getDefaultWorkerPool() that would be perfect.

westito commented 3 months ago

Any update or workaround? I try to use Micronaut with Coroutines but this issue makes it impossible to do

KazimirDobrzhinsky commented 2 weeks ago

Any updates on this? It cause quite big problem on using Hibernate reactive with Micronaut/Quarkus frameworks

gavinking commented 2 weeks ago

I mean the rule here is that the reactive session is tied to a given Vert.x "duplicated" context. You can't share a reactive session between different contexts. This is exactly analogous to how you can't share a session between threads in regular Hibernate.

So you need to ensure that all accesses to a given session happen within the same Vert.x duplicated context.

gavinking commented 2 weeks ago

https://quarkus.io/guides/duplicated-context

dstepanov commented 2 weeks ago

Can somebody from the Hibernate team provide an example of how to schedule the operation back to the proper context?

gavinking commented 2 weeks ago

Probably not, since we're not experts in either Vert.x or micronaut. I think you would have more luck asking the Vert.x community.

dstepanov commented 2 weeks ago

It can be raw Hibernate Reactive; I will adopt it for Micronaut Data. I just want to see if it's possible. Last time, I spent quite some time and didn't find a way to do it.

gavinking commented 2 weeks ago

I mean if you're just talking about calling out to the database or HTTP then my understanding is that in principle Vert.x is supposed to process the response on the same duplicated context automatically. But there were cases where that wasn't working in Quarkus, which I believe they had to fix on the Quarkus side. But I don't know the details.