Skip to content

[pull] main from quarkusio:main#823

Merged
pull[bot] merged 10 commits intobschuhmann:mainfrom
quarkusio:main
Apr 13, 2026
Merged

[pull] main from quarkusio:main#823
pull[bot] merged 10 commits intobschuhmann:mainfrom
quarkusio:main

Conversation

@pull
Copy link
Copy Markdown

@pull pull Bot commented Apr 13, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

jmartisk and others added 10 commits April 13, 2026 08:40
…sSession

This test confirms that blocking Hibernate ORM already allows using both
regular Session and StatelessSession within the same transaction. Both
session types can be used together, and changes from both are properly
committed or rolled back together.

This serves as a reference implementation before enabling the same
capability in Hibernate Reactive.

Assisted-By: Claude Code <noreply@anthropic.com>
… package

Because that's the convention for classes that are not API.
Technically this should be SPI, but since for now we only intend to
use these classes in the core Quarkus project, this will do.
…eactive-transactions

Moved TransactionalContextPool and TransactionalContextConnection from
hibernate-reactive to reactive-transactions module, as they are not specific
to Hibernate Reactive and are used by the transaction interceptors.

Additionally, introduced getCurrentConnectionFromVertxContext() method in
TransactionalContextPool for consistent access to the current connection
from the Vert.x context.

Assisted-By: Claude Code <noreply@anthropic.com>
…action

This change removes the artificial restriction that prevented using both
Mutiny.Session and Mutiny.StatelessSession within the same @transactional
method in Hibernate Reactive, bringing it in line with blocking Hibernate ORM.

Key changes:
- Added thread-safe connection reuse in TransactionalContextPool: when a
  second session type requests a connection within the same transaction, it
  reuses the existing connection from the Vert.x context. Uses VarHandle
  with compareAndSet to prevent race conditions when both session types
  request connections concurrently.
- Extracted ConnectionHolder as a package-protected class that ensures only
  one connection is created per transaction even with concurrent access,
  using a Promise pattern inspired by Hibernate Reactive's ProxyConnection
- Made TransactionalContextConnection.close() a no-op to prevent premature
  connection closure, letting only TransactionalInterceptorBase close the
  actual connection at transaction end
- Changed TransactionalContextPool.getCurrentConnectionFromVertxContext() to
  return a Future instead of the connection directly, allowing callers to
  handle async connection availability
- Updated TransactionalInterceptorBase.connectionFromContext() to return
  Uni<SqlConnection> and all its callers to handle null checks before
  converting to Uni
- Updated TransactionalInterceptorBase to use
  TransactionalContextPool.closeAndClearCurrentConnection() to properly
  close the connection and clear it from the Vert.x context
- Removed validation checks in HibernateReactiveRecorder that threw
  IllegalStateException when mixing session types
- Transformed MixStatelessStatefulSessionTest from negative (expecting
  failures) to positive tests verifying both session types work together,
  share connections, and commit/rollback together
- Updated documentation to explain that mixing is now supported and both
  session types share the same underlying connection

Both session types can now coexist in the same transaction, using the
appropriate session type for different operations (e.g., StatelessSession
for bulk operations, regular Session for operations requiring caching).

Fixes #52828

Assisted-By: Claude Code <noreply@anthropic.com>
Allow using both of Hibernate Reactive's CDI-injected `Session` and `StatelessSession` in the same transaction when using `@Transactional`
…heck

Fix wording error and add null check
Remove the org.lz4 exclusion, it's no longer necessary
@pull pull Bot locked and limited conversation to collaborators Apr 13, 2026
@pull pull Bot added the ⤵️ pull label Apr 13, 2026
@pull pull Bot merged commit 22e97d8 into bschuhmann:main Apr 13, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants