Decoupling the @Asynchronous annotation from the EJB component model

[glassfishrobot]

Currently the EJB @Asynchronous annotation can only be used with the EJB component model. With the introduction of managed beans and CDI, there are not many good technical reasons why the @Asynchronous annotation should not be used in managed beans as well. In fact, many developers that are wary of the EJB component model would opt to use this model instead. In addition, decoupling EJB services such as @Asynchronous from the component model moves towards removing one-off component models in Java EE in favor of unifying around managed beans/CDI.

We currently allow this capability in Resin. The code looks like this:

@ApplicationScoped public class MyAsyncBean { ... @Asynchronous public void myAsyncTask()

{ ... }

... }

It should also be possible to use @Asynchronous in CDI stereotypes so that developers can compose custom component types to meet the needs of their individual applications. The code for this could look like the following:

@ApplicationScoped @Stereotype @Retention(RUNTIME) @Target(TYPE) @Asynchronous public @interface AsyncTask {}

Now, one outstanding item we did not resolve in Resin is the SessionContext.wasCancelCalled() method in managed beans, primarily because we did not want to introduce new APIs for EJB functionality and wanted to stick to what was available in the standard.

Affected Versions

[3.2]

[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