Decoupling the @Asynchronous annotation from the EJB component model about ejb-spec

[glassfishrobot]

Reported by reza_rahman

[glassfishrobot]

reza_rahman said:
One logical place for a decoupled @asynchronous annotation could be the Java EE concurrency utilities.

[glassfishrobot]

mercnboy3 said:
+1 as in the other EJB decouplings, it seems like a package change would be in order.

[glassfishrobot]

emailnbw said:
+1, again as long as this is backwards compatible and things remain consistent. For example, per the spec an implicit REQUIRES_NEW tx is started on its boundary in EJB land. It does raise the issue of consistency when used in a CDI context. If @asynchronous does not have TX implications in CDI by default the developer will have to understand the differences in contexts. If there is @transactional @Asychronous on a CDI bean then that @transactional should be a @transactional(requiresNew = true).

Also it would be nice to make this consistent with the Servlet 3.0 spec's async functionality so that there would be one @asynchronous to rule them all.

[glassfishrobot]

reza_rahman said:
An updated @asynchronous should quite possibly take advantage of Java SE 8 CompletableFuture as a superior result processing model?

[glassfishrobot]

agoncal said:
The CDI 2.0 EG is thinking of having asynchronous events. It would be a shame to have several manners to have asynchronous calls (EJB, CDI, Servlet, JAX-RS....). Why not having a javax.annotation.Asynchronous common to every spec, and each spec defines its own way of dealing with asynchronous calls ? And I agree with Reza, why not dealing with CompletableFuture ?

[glassfishrobot]

gastaldi said:
+1 in having a javax.annotation.Asynchronous and encouraging the usage of CompletableFuture

[glassfishrobot]

Was assigned to mvatkina

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-3