Hibernate Reactive 2.4.6 combined with Panache can violate transaction boundaries

[markusdlugi]

Describe the bug

We tried to update our application to use Hibernate Reactive 2.4.6 to fix hibernate/hibernate-reactive#2007. While most of our tests worked, we observed one behavior that is concerning and indicates to us that the transaction boundaries are not respected correctly. Specifically, this seems to happen when mixing Panache and Vanilla Hibernate Reactive, e.g. because some specific queries need a SessionFactory.

One example we observed:

• Fetch an entity using Panache repository with PESSIMSTIC_WRITE lock and then wait (using a delay)
• Fetch the same entity using SessionFactory with PESSIMISTIC_WRITE
• Observe that both transactions obtain the lock at the same time (or rather, it seems to be a single transaction instead of two distinct ones?)

Expected behavior

We expect transaction boundaries to be respected. In the given example, the second transaction should need to wait until the first transaction released the lock before it can acquire it.

Actual behavior

As described, locks can be shared between seemingly distinct transactions. Most likely there are other negative side effects.

How to Reproduce?

Reproducer: https://github.com/markusdlugi/hr-transaction-reproducer

Steps to reproduce the behavior:

1. Run CounterResourceTest
2. Observe that should_increase_count_sequentially_using_only_panache() is always successful, while should_increase_count_sequentially_using_panache_and_hr_session() will occasionally fail
3. Change dependency to use Hibernate Reactive 2.4.5.Final
4. Observe that all tests are successful

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

3.21.1

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

No response

Additional information

This behavior can only be reproduced with Hibernate Reactive 2.4.6.Final. Using HR 2.4.5.Final, everything is working as expected.

We suspect that hibernate/hibernate-reactive#2198 might be the root cause, but not quite sure.

[quarkus-bot]

/cc @DavideD (hibernate-reactive), @FroMage (panache), @gavinking (hibernate-reactive), @loicmathieu (panache)

[DavideD]

We suspect that hibernate/hibernate-reactive#2198 might be the root cause, but not quite sure.

I think you are right. I've tried to run the test with a version of Hibernate Reactive without these changes and it seems to work. @tsegismont, any idea?

[markusdlugi]

Thanks for investigating. I tried to debug it a little as well. To me it seemed like both streams in the test, even though they ran on two separate threads, ended up with the same Hibernate session. Which explains why the second transaction was able to acquire the lock even though the first transaction didn't release it yet. Not sure why that happens, and why only when mixing Panache and regular SessionFactory, though...

[DavideD]

So, the issue is definitely because of the changes in the VertxContext where we removed the use of the deprecated methods.
The reason the test pass when using only panache, it's because it's still using the old approach:

quarkus/extensions/panache/hibernate-reactive-panache-common/runtime/src/main/java/io/quarkus/hibernate/reactive/panache/common/runtime/SessionOperations.java

Line 67 in 69e41f6

if (context.getLocal(SESSION_ON_DEMAND_KEY) != null) {

I've updated the test on my remote repository and only use Hibernate Reactive now, it always fails with 2.4.6.Final (works with 2.4.5.Final): markusdlugi/hr-transaction-reproducer@master...DavideD:hr-transaction-reproducer:test-only-hr

I suspect we need to update something in Quarkus, but I will continue to have a look to see if I can figure out the exact issue.

[DavideD]

I sent a drat PR here: #47441
But I will need a new Hibernate Reactive release (probably).