Transaction errors using non-blocking/reactive resources and jOOQ.

[jdussouillez]

Hi!
We are migrating our Web API from imperative to reactive and we are facing some issues (than we can "fix" using dirty hacks) so I would like to know which is the best way to do it.

Our problem is the @Transactional annotation (we're using jOOQ with quarkus-jooq module), since we migrated to reactive, the code below fails :

2022-10-17 11:02:50,951 ERROR [org.jbo.res.rea.ser.cor.RuntimeExceptionMapper] (vert.x-eventloop-thread-4) A blocking operation occurred on the IO thread.
This likely means you need to annotate com.myapp.resources.BrandResource#get(class java.lang.String) with @io.smallrye.common.annotation.Blocking.
Alternatively you can annotate the class com.myapp.resources.BrandResource to make every method on the class blocking, or annotate your sub class of the javax.ws.rs.core.Application class to make the whole application blocking

@Path("/brand")
public class BrandResource {

    @Inject
    protected BrandService brandService;

    @GET
    @Path("{id}")
    @Produces(MediaType.APPLICATION_JSON)
    public Uni<Brand> get(@PathParam("id") final String id) {
        return brandService.get(id)
            .log()
            .map(Optional::orElseThrow)
            .onFailure(NoSuchElementException.class)
            .transform(ex -> new BrandNotFoundException());
    }
}

@ApplicationScoped
public class BrandService {

    @Inject
    protected DSLContext dslContext;

    @Transactional
    public Uni<Optional<Brand>> get(final String id) {
        return Uni.createFrom()
            .publisher(baseQuery().where(APP.BRANDS.ID.eq(id)))
            .map(rec -> Optional.ofNullable(rec).map(r -> r.into(Brand.class)));
    }

    private SelectJoinStep<?> baseQuery() {
        return dslContext
            .select(
                APP.BRANDS.ID,
                APP.BRANDS.LABEL
            )
            .from(APP.BRANDS);
    }

Here's two ways of fixing it :

Remove the @Transactional annotation

Logs :

2022-10-17 11:05:27,414 INFO  [io.qua.mut.run.MutinyInfrastructure] (vert.x-eventloop-thread-4) Uni.UniOnItemTransform.0 | onSubscribe()
2022-10-17 11:05:27,420 INFO  [io.qua.mut.run.MutinyInfrastructure] (reactor-tcp-epoll-1) Uni.UniOnItemTransform.0 | onItem(Optional[com.myapp.beans.Brand@4ed78540])
2022-10-17 11:05:27,421 INFO  [io.qua.htt.access-log] (vert.x-eventloop-thread-4) 127.0.0.1 - - 17/Oct/2022:11:05:27 +0200 "GET /api/brand/e310ad24-fd58-11e8-8c9a-005056867867 HTTP/1.1" 200 63

Run the call to BrandService::get in the subscription on a worker thread

Here, the @Transactional annotation works fine if we change the resource code to something like this :

public Uni<Brand> get(@PathParam("id") final String id) {
    // Very quick & dirty hack but now it works
    return Uni.createFrom().voidItem()
        .runSubscriptionOn(Infrastructure.getDefaultWorkerPool())
        .chain(() -> brandService.get(id))
        .log()
        .map(Optional::orElseThrow)
        .onFailure(NoSuchElementException.class)
        .transform(ex -> new BrandNotFoundException());
}

Logs :

2022-10-17 11:08:16,217 INFO  [io.qua.mut.run.MutinyInfrastructure] (executor-thread-0) Uni.UniOnItemTransformToUni.0 | onSubscribe()
2022-10-17 11:08:16,222 INFO  [io.qua.mut.run.MutinyInfrastructure] (reactor-tcp-epoll-2) Uni.UniOnItemTransformToUni.0 | onItem(Optional[com.myapp.beans.Brand@7ef641e5])
2022-10-17 11:08:16,224 INFO  [io.qua.htt.access-log] (vert.x-eventloop-thread-4) 127.0.0.1 - - 17/Oct/2022:11:08:16 +0200 "GET /api/brand/e310ad24-fd58-11e8-8c9a-005056867867 HTTP/1.1" 200 63

---

Both workarounds are just hacks to make it work. Do you guys know how to handle this correctly ?

[jdussouillez]

Ok, so it seems to be working when using the @Transactional annotation on the resource endpoint instead of the service method. Is it the recommended solution ?

@GET
@Path("{id}")
@Produces(MediaType.APPLICATION_JSON)
@Transactional
public Uni<Brand> get(@PathParam("id") final String id) {
    return brandService.get(id)
        .log()
        .map(Optional::orElseThrow)
        .onFailure(NoSuchElementException.class)
        .transform(ex -> new BrandNotFoundException());
}

2022-10-18 09:12:36,611 INFO  [io.qua.mut.run.MutinyInfrastructure] (executor-thread-0) Uni.UniOnItemConsume.0 | onSubscribe()
2022-10-18 09:12:41,615 INFO  [io.qua.mut.run.MutinyInfrastructure] (reactor-tcp-epoll-4) Uni.UniOnItemConsume.0 | onItem(Optional[com.myapp.beans.Brand@6eccb510])
2022-10-18 09:12:41,621 INFO  [io.qua.htt.access-log] (executor-thread-0) 127.0.0.1 - - 18/Oct/2022:09:12:41 +0200 "GET /api/brand/e310ad24-fd58-11e8-8c9a-005056867867 HTTP/1.1" 200 63

---

Edit: with this solution, the dev UI is telling my endpoint reactive score is only 66/100.

[jdussouillez]

I can get it to 100% by forcing it as NonBlocking as the doc says : https://quarkus.io/guides/resteasy-reactive

If a method or class is annotated with javax.transaction.Transactional then it will also be treated as a blocking method. This is because JTA is a blocking technology, and is generally used with other blocking technology such as Hibernate and JDBC. An explicit @Blocking or @nonblocking on the class will override this behaviour.

@GET
@Path("{id}")
@Produces(MediaType.APPLICATION_JSON)
@Transactional
@NonBlocking
public Uni<Brand> get(@PathParam("id") final String id) {
    // ...
}

But now my endpoint fails because it can't start a transaction on a non blocking thread, which is normal.

Caused by: io.quarkus.runtime.BlockingOperationNotAllowedException: Cannot start a JTA transaction from the IO thread.
	at io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:30)

---

So I guess all @Transactional operations should be annotated on the resource endpoint, and if there are then they can't be 100% reactive. Is this correct ?

So for my endpoints, there are 2 possibilities :

1. I need a transaction

• I add the annotation @Transactional on my resource endpoint
• My endpoint returns a Uni/Multi but the @Transactional annotation makes it blocking, so I see it as only 66% reactive in the dev UI. But this is normal. And also it's worth saying that the doc says the performances of blocking RESTEasy reactive requests is still better than RESTEasy Classic endpoints :

However, an endpoint method using @Blocking in RESTEasy Reactive still achieves around 50% higher throughput than the same method using RESTEasy Classic. (https://quarkus.io/blog/resteasy-reactive-faq/#what-is-the-performance-implication-of-using-blocking)

2. I don't need a transaction

• No @Transactional annotation.
• My endpoint returns a Uni/Multi, so it will be executed on the I/O thread (better throughput than the worker thread for process with short execution time)