ejb-spec
  1. ejb-spec
  2. EJB_SPEC-3

Decoupling the @Asynchronous annotation from the EJB component model

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2
    • Fix Version/s: Future version
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        reza_rahman added a comment -

        One logical place for a decoupled @Asynchronous annotation could be the Java EE concurrency utilities.

        Show
        reza_rahman added a comment - One logical place for a decoupled @Asynchronous annotation could be the Java EE concurrency utilities.
        Hide
        Kerry Wilson added a comment -

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

        Show
        Kerry Wilson added a comment - +1 as in the other EJB decouplings, it seems like a package change would be in order.
        Hide
        emailnbw added a comment - - edited

        +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.

        Show
        emailnbw added a comment - - edited +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.
        Hide
        reza_rahman added a comment -

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

        Show
        reza_rahman added a comment - An updated @Asynchronous should quite possibly take advantage of Java SE 8 CompletableFuture as a superior result processing model?
        Hide
        Antonio Goncalves added a comment -

        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 ?

        Show
        Antonio Goncalves added a comment - 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 ?
        Hide
        gastaldi added a comment -

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

        Show
        gastaldi added a comment - +1 in having a javax.annotation.Asynchronous and encouraging the usage of CompletableFuture

          People

          • Assignee:
            marina vatkina
            Reporter:
            reza_rahman
          • Votes:
            15 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated: