Quarkus 2.8.0 Introduces Fine-Grained Transaction API

Red Hat has released Quarkus 2.8.0 that delivers integration with the RESTEasy Reactive REST layer and GraalVM 22.0 by default. A fine-grained programmatic transaction API offers more control over transactions.

Quarkus 1.11 introduced the RESTEasy Reactive integration, a reactive implementation of JAX-RS and implemented with Vert.x. With this version, RESTEasy Reactive is now the default implementation and supports blocking and reactive calls, automatically selected depending on the return type of the endpoint. For example, returning a Student makes the endpoint blocking, whereas returning a Uni<Student> makes the endpoint reactive. Until recently, the default REST layer was RESTEasy Classic, and it is still available after manual addition to the project dependencies.

All the quarkus-resteasy* dependencies of a REST server should be replaced by quarkus-resteasy-reactive* dependencies, except for the quarkus-resteasy-mutiny dependency since the functionality is integrated in RESTEasy Reactive. After that the various annotations, such as org.jboss.resteasy.annotations.jaxrs.QueryParam, should be replaced by the org.jboss.resteasy.reactive* annotations such as org.jboss.resteasy.reactive.RestQuery.

Similarly, REST client implementations should replace the quarkus-rest-client* dependencies by the new quarkus-rest-client-reactive* dependencies.

The RESTEasy Reactive migration guide and the reference guide offer further migration guidance.

The QuarkusTransaction API now offers a programmatic API to control transactions by explicitly calling the begin() and commit() methods:

QuarkusTransaction.begin();
// implementation
QuarkusTransaction.commit();

This transaction is tied to the CDI request scope and automatically rolls back whenever an exception destroys the request scope. Alternatively, it's possible to start the transaction with a timeout and rollback whenever the timeout occurs:

QuarkusTransaction.begin(QuarkusTransaction.beginOptions()
    .timeout(42));
// implementation
QuarkusTransaction.rollback();

Lambda scoped transactions offer another alternative by executing a Runnable within a transaction:

QuarkusTransaction.run(() -> {
	// implementation
});

Alternatively, a Callable solution may be used which supports exception handling and the enumeration semantics DISALLOW_EXISTING, JOIN_EXISTING, SUSPEND_EXISTING, REQUIRE_NEW (default):

int answer = QuarkusTransaction.call(QuarkusTransaction.runOptions()
    .timeout(21)
    .exceptionHandler((throwable) -> {
    if (throwable instanceof RuntimeException) {
        return RunOptions.ExceptionResult.COMMIT;
    }
    return RunOptions.ExceptionResult.ROLLBACK;
    })
    .semantic(RunOptions.Semantic.REQUIRE_NEW), () -> {
    // implementation
    return 42;
});

GraalVM 22.0, already supported with the release of Quarkus 2.7, is now used by default, offering improved logging when building a native image.

Quarkus now supports Proof Of Key for Code Exchange (PKCE) for OpenID Connect (OIDC), an identity layer on top of the OAuth 2.0 protocol. PKCE is an extension to OAuth 2.0 to mitigate security threats when a public client requests an access token.

The maintainers decided to remove AssertJ from the Bill of Materials (BOM) as new versions often broke the binary compatibility. Projects should now explicitly declare AssertJ 3.22.0, currently the latest version.

Elasticsearch Dev Services automatically starts an Elasticsearch container when running tests in dev and test mode when an Elasticsearch extension is used unless explicitly disabled with, for instance, quarkus.devservices.enabled set to false.

Quarkus offers a migration guide to ease the transition to version 2.8.0.