Hibernate Reactive and @Transactional

[DavideD]

I don't think we can integrate with Jakarta Transactions considering that's a blocking API.

But we should be able to work with @Transactional within some clear limitations. "Clear" in the sense that we should be able to throw an exception if the user tries to use it improperly. For example, when trying to use Hibernate Reactive with any real transactional resource.

Also, Hibernate Reactive uses different transactions for a Session and a StatelessSession, even if they are in the same transaction scope. This happens without any warning to the user. We could change the behaviour or throws an exception when we detect it.

NOTE: We may want to also handle @QuarkusTransactional, see #50119

NOTE: This is separate from the discussion about allowing to inject HR Session/StatelessSession, see #47462

[quarkus-bot]

/cc @gavinking (hibernate-reactive)

[yrodiere]

Integration with Jakarta Transactions proper is not technically possible right now, since transaction managers are blocking.

What we could investigate is hijacking the @Transactional annotation so that it works with Hibernate Reactive: the retrieval of a Hibernate Reactive Session (or StatelessSession, or Uni<Session>, or ...) from CDI within the context of a @Transactional annotation would always return the same session, using the same transaction.

Of course, this would not provide two-phase commits or anything like that, but it would provide a developer experience similar to @Transactional with blocking code.

Implementation wise:

1. We'd implement a CDI interceptor on @Transactional that would set up a scope, or context, or whatever, which could then serve as the basis for the next steps.
2. We'd write something in the Hibernate Reactive extension similar to

   quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/session/TransactionScopedSession.java

   Line 70 in b0703dd

   public class TransactionScopedSession implements Session {

   , which would provide the core of the feature.
3. We should IMO implement checks that trigger failures when using both "reactive transactions" and the transaction manager. (see also Forbid/discourage connecting to the same database through Hibernate using both blocking and reactive in the same request #46756)
4. @tsegismont mentioned some work could be necessary in Vert.x SQL clients, but I don't remember what that was :x
5. We'll probably want to implement something similar to what Agroal does, but for Vert.x SQL clients: something that can be injected through CDI (a "transaction connection"?) with a guarantee that when used within a transaction, it always returns the same connection. We could use that in the Hibernate Reactive integration, but we don't necessarily need it; it's more for consistency and to avoid surprises.
   There are probably other problems, but from what I read in quarkus-hibernate-reactive does not make StatelessSession available for injection #47462 , things are relatively optimistic on the CDI front at least.

[yrodiere]

@umidAhmad Please don't hijack topics with unrelated questions. Repeated offenses can lead to bans.
Create your own topic instead, preferably in GitHub Discussions: https://github.com/quarkusio/quarkus/discussions

[arjantijms]

Integration with JTA proper is not technically possible right now, since transaction managers are blocking.

Small remark, but it's "Jakarta Transactions" now. We did away with the obscure abbreviations ;)

[tsegismont]

• @tsegismont mentioned some work could be necessary in Vert.x SQL clients, but I don't remember what that was :x

Not sure what you're referring to 😅

I wondered at some point if the Vert.x Transaction object implemented SqlClient but it doesn't.

• We'll probably want to implement something similar to what Agroal does, but for Vert.x SQL clients: something that can be injected through CDI (a "transaction connection"?) with a guarantee that when used within a transaction, it always returns the same connection. We could use that in the Hibernate Reactive integration, but we don't necessarily need it; it's more for consistency and to avoid surprises.

@FroMage I think you mentioned somewhere you got this working in some PoC, perhaps can you explain your solution?

[FroMage]

Yeah. So, I had transaction-scoped pgclient as done here: FroMage@663df8f#diff-fefc9ae05df54282c28f6a9b93f6787b7733bab4466ed09ae5f10af4c618dbcb and here: FroMage@663df8f#diff-16acc852021bc1db5a74b5d353bee0512f9630a262cba4b1a839ef2245203f17

But now I remember what the problem was: Narayana did not support reactive operations: FroMage@663df8f#diff-16acc852021bc1db5a74b5d353bee0512f9630a262cba4b1a839ef2245203f17R64-R67

So… 🤷

If I were to retry something like this, I'd do it differently and do a mix of this and the current @Transactional interceptor and @WithTransaction interceptor:

• Mark HR session/transaction as lazily opened
• Open HR session on demand, or TX if @Transactional marked us as requiring a TX
• Do the tx.commit/rollback in the @Transactional interceptor at the end of the Uni pipeline, IFF we ended up opening a TX
• Do the session.close in the @Transactional interceptor at the end of the Uni pipeline, IFF we ended up opening a session

But also, start with:

Throw an exception if at any point more than one of the following sessions get lazily opened:

• Stateless blocking
• Managed blocking
• Stateless reactive
• Managed reactive

We may relax that later, but let's not deal with that now.

[yrodiere]

Relevant:

https://x.com/1ovthafew/status/1922595735549157690
https://github.com/gavinking/reactive-data-demo-quarkus-mvn/tree/main/src/main/java/org/example

[yrodiere]

EDIT: Cross-posted by mistake, sorry. See an important message relevant to this conversation here: #47462 (comment)

[gavinking]

I guess the thing that makes me uncomfortable with this is that it creates a dependency from user code on the JTA jar for one annotation.

I would be more comfortable with the idea if we supported somewhat more of the JTA API. But I don't see us allowing injection of a UserTransaction (whose API is blocking). I don't even think that Synchronization is quite right.

One extra thing we could support is the @TransactionScoped annotation. Currently we don't have any sort of transaction context in Hibernate Reactive, but I believe it would be quite straightforward to add. I can expose stuff like that via Mutiny.Transaction, I believe. It would need to have some sort of internal hashtable, and it would not to have before/after completion callbacks. But both these things are generally-useful.

[yrodiere]

I guess the thing that makes me uncomfortable with this is that it creates a dependency from user code on the JTA jar for one annotation.

We could just have a custom annotation that works for reactive only (or both reactive and blocking, whatever) for people that don't have a dependency to JTA. And still have @Transactional work correctly on reactive beans (e.g. on Rest resources mixing blocking and reactive) -- for convenience.

[gavinking]

@FroMage

• Mark HR session/transaction as lazily opened
• Open HR session on demand, or TX if @transactional marked us as requiring a TX

Nah, doing this stuff lazily means that the things you inject have to be Uni<StatelessSession> instead of just StatelessSession, and that is viral so that then any Jakarta Data repository you inject has to be also injected as a Uni<Library> or whatever.

The trick to avoid this mess is to do open things eagerly, just like what happens in my code which makes use of SessionFactory.withStatelessTransaction().

• Do the tx.commit/rollback in the @transactional interceptor at the end of the Uni pipeline, IFF we ended up opening a TX
• Do the session.close in the @transactional interceptor at the end of the Uni pipeline, IFF we ended up opening a session

Right, just like what SessionFactory.withStatelessTransaction() does. It ultimately calls:

Uni<T> execute(Function<Mutiny.Transaction, Uni<T>> work) {
	currentTransaction = this;
	return begin()
		.chain( () -> executeInTransaction( work ) )
		.eventually( () -> currentTransaction = null );
}

/**
 * Run the code assuming that a transaction has already started so that we can
 * differentiate an error starting a transaction (and therefore doesn't need to rollback)
 * and an error thrown by the work.
 */
Uni<T> executeInTransaction(Function<Mutiny.Transaction, Uni<T>> work) {
	return work.apply( this )
		// in the case of an exception or cancellation
		// we need to rollback the transaction
		.onFailure().call( this::rollback )
		.onCancellation().call( this::rollback )
		// finally, when there was no exception,
		// commit or rollback the transaction
		.call( () -> rollback ? rollback() : commit() );
}