Quarkus gives a lot of reactive experience to use: Mutiny as a base, Vert.x & RxJava under the hood, CompletableFutures, Reactor available via mappers within Mutiny. All of these use different execution model - blocking / non-blocking I/O, ForJoinPool executor or dedicated, ewith backpressure or without etc. What is the ideomatic way to be reactive in Quarkus and not to kill Vert.x living under the hood with blocking call?
It was my point about ovelapping functionality in the underlying frameworks. So @JBaruch can merge them into one.
Quarkus gives a lot of reactive experience to use: Mutiny as a base, Vert.x & RxJava under the hood, CompletableFutures, Reactor available via mappers within Mutiny. All of these use different execution model - blocking / non-blocking I/O, ForJoinPool executor or dedicated, ewith backpressure or without etc. What is the ideomatic way to be reactive in Quarkus and not to kill Vert.x living under the hood with blocking call?
Is there a way to use programmatic transacion management (like Spring transactionTemplate)? Comapred with Transactional annotation which spans on all the method
Is there a way to use programmatic transacion management (like Spring transactionTemplate)? Comapred with Transactional annotation which spans on all the method