Description
As a:
...I need to be able to:
write repository methods that run asynchronously
...which enables me to:
avoid tying up the requesting thread waiting for queries to finish so that I can complete other work in the mean time.
Note: This issue does not cover reactive programming models like Flow. That is a separate discussion.
The preference would be to rely on the data access provider's own async support, but Jakarta Persistence/JPA (which are JDBC based) doesn't have async support. Lacking that, Jakarta Concurrency @Asynchronous could provide what we need in this area and fit quite well with just some minor language added to the Jakarta Data spec to make it possible.
If we specify that repository methods can have return types of CompletionStage and CompletableFuture (as some implementations already do), then based on the data access provider's level of support for async:
- If the data access provider has its own async support, use that and the stage/future just gets completed with the result upon completion.
- Otherwise, Jakarta Data could state that if a repository interface method is annotated with Concurrency
@Asynchronous then that same @Asynchronous annotation is also applied to the bean instance. Doing that will automatically trigger the Concurrency 3.0 interceptor. Then all the implementation needs to do is return an already-completed future, relying on the Concurrency @Asynchronous interceptor to cover making it async.
@Asynchronous
CompletionStage<List<Customer>> findByNumOrdersGreaterThan(int threshold);
...
findByNumOrdersGreaterThan(2).thenAccept(this::sendLastestSalesPromotion);
Other benefits of this will be that if the data access provider, such as based on a Jakarta Persistence/JPA implementation, requires the async thread to have services of the Jakarta EE platform available, such as performing a java:comp/env lookup of a data source, or to be able to run under a transaction, or to have the same security credentials on the thread for performing the database operation, the Jakarta Concurrency spec will have taken care of all of that for us.
Description
As a:
...I need to be able to:
write repository methods that run asynchronously
...which enables me to:
avoid tying up the requesting thread waiting for queries to finish so that I can complete other work in the mean time.
Note: This issue does not cover reactive programming models like Flow. That is a separate discussion.
The preference would be to rely on the data access provider's own async support, but Jakarta Persistence/JPA (which are JDBC based) doesn't have async support. Lacking that, Jakarta Concurrency @Asynchronous could provide what we need in this area and fit quite well with just some minor language added to the Jakarta Data spec to make it possible.
If we specify that repository methods can have return types of CompletionStage and CompletableFuture (as some implementations already do), then based on the data access provider's level of support for async:
@Asynchronousthen that same@Asynchronousannotation is also applied to the bean instance. Doing that will automatically trigger the Concurrency 3.0 interceptor. Then all the implementation needs to do is return an already-completed future, relying on the Concurrency@Asynchronousinterceptor to cover making it async.Other benefits of this will be that if the data access provider, such as based on a Jakarta Persistence/JPA implementation, requires the async thread to have services of the Jakarta EE platform available, such as performing a java:comp/env lookup of a data source, or to be able to run under a transaction, or to have the same security credentials on the thread for performing the database operation, the Jakarta Concurrency spec will have taken care of all of that for us.