Support @Transactional for Hibernate Reactive

[lucamolteni]

Introduces a new extension enabling @Transactional annotation support for Hibernate Reactive. This allows developers to use familiar transaction semantics with reactive database operations.

Key implementation details:

• New quarkus-reactive-transactions extension with dedicated CDI interceptors
• TransactionalContextPool wraps the SQL client pool to lazily open transactions based on Vert.x context flags set by the @transactional interceptor
• TransactionalInterceptorBase manages the complete transaction lifecycle (begin, commit, rollback) within the reactive Uni pipeline
• TransactionalContextConnection wrapper prevents premature connection closure before transaction commit/rollback
• OpenedSessionState refactored from Panache to centrally manage session lifecycle and caching (possibly to be reused in Panache as well)
• Validation prevents mixing @transactional with @WithTransaction and @WithSessionOnDemand annotations to avoid conflicting transaction semantics
• Disable JTA interceptor execution for methods returning Uni to prevent mixups

Limitations:

• Currently supports only Transactional.TxType.REQUIRED, other TxType values throw UnsupportedOperationException

Dependencies updated:

• hibernate-orm.version → 7.2.0.CR1
• hibernate-reactive.version → 3.2.0-SNAPSHOT

Fixes #47462 Fixes #47698

Support @Transactional on Reactive methods as well Injection of Mutiny.Session as injectable bean

[quarkus-bot[bot]]

/cc @gsmet (hibernate-orm)

[lucamolteni]

@yrodiere @FroMage this is the first Draft of the @Transactional support on Reactive

Here's what it's currently missing on my todo list

• Reduplicate the Vert.x context every time with have a @Transactional annotation (be aware that doing this will break putting stuff inside the Vert.x context) -
• TransactionalInterceptorBase: Handle checked exception vs runtime exception differently according to the spec copy the logic from io/quarkus/narayana/jta/runtime/interceptor/TransactionalInterceptorBase.java:363
• withTransactionalSessionOnDemand check that there's no other session opened by session delegators for another PU
• withTransactionalSessionOnDemand check that there's no statelessSession opened by statelessSession delegators
• MixReactiveTransactional (old annotation)
• MixStatelessStatefulSessionTest
• In TransactionalContextPool we create a new transaction if needed, but nobody updates the reference inside the MutinySession (currentTransaction) so if a user access it it seems like transaction is null, while instead it's running
• Test extra transactional state
• Test also when you put @Transactional on a method where you pass a Uni as a parameter, I'm not sure it works. If that's the case it'll break the experience for the users

[lucamolteni]

Also @DavideD take a look at this please

[mmusgrov]

Will we be able to re-enable the JTA interceptor if we can arrive at a non-blocking API. We discussed the issues on the protean-dev email list (subject "Non blocking transaction manager") a while ago.

I have recently been improving on the API prototype implementation that Stephane helped to develop which:

• defines a non blocking API based on mutiny
• for XA calls the work is done on a virtual thread and we wait for those to finish, this is non-negotiable since XA is a blocking protocol (things like enlist and prepare etc must wait for concensus before moving onto the next phase of the protocol)

We still need to do some thinking/work for the non XA case, "e.g. where one could use the Vert.x SQL Drivers API, where we can be fully non blocking". I'd expect the changes to Arjuna Core to support that will be more invasive than simply providing the reactive API.

[yrodiere]

Awesome to see efforts are continuing on that side too, thanks for the update @mmusgrov!

As far as I can see, when this becomes available, we should be able to switch out part of @lucamolteni's work (based on local transactions) in favor of Narayana -- but all the testing and some of the plumbing will stay. So... no need to stop what you're working on @lucamolteni :)

EDIT: and of course all the Hibernate-related work will live on as well :)