Details

    • Type: Feature Request Feature Request
    • Status: Open Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: TBD
    • Component/s: Events
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      Consider including asynchronous events as their were specified in one of the previous drafts.

        Activity

        Hide
        Jonathan Fisher
        added a comment - - edited

        @Mark That is an excellent point, but, it sounds like we're dismissing this prematurely without quantifying your statement.

        I believe that the server could use a TaskExecutor internally and establish a thread pool to set limits on the resources consumed by something marked as @ Asynchronous. This is a fairly common pattern, and nothing out of the ordinary. I think the only thing that complicates this is scoped CDI beans.

        The first possibility is we say each @Async execution is independent. This would be incredibly easy to implement, and it would be on the developer to pass any state (via the Event). Essentially, each @Async event operates in it's own transaction, request context, etc.

        More in the spirit of CDI is to preserve the request context, transaction context, etc when executing an Async request. This is a fairly difficult implementation, but it's been done before with EJB, and perhaps that model could be simplified for CDI.

        Lets discuss the complications that I did not take into account...

        Show
        Jonathan Fisher
        added a comment - - edited @Mark That is an excellent point, but, it sounds like we're dismissing this prematurely without quantifying your statement. I believe that the server could use a TaskExecutor internally and establish a thread pool to set limits on the resources consumed by something marked as @ Asynchronous. This is a fairly common pattern, and nothing out of the ordinary. I think the only thing that complicates this is scoped CDI beans. The first possibility is we say each @Async execution is independent. This would be incredibly easy to implement, and it would be on the developer to pass any state (via the Event). Essentially, each @Async event operates in it's own transaction, request context, etc. More in the spirit of CDI is to preserve the request context, transaction context, etc when executing an Async request. This is a fairly difficult implementation, but it's been done before with EJB, and perhaps that model could be simplified for CDI. Lets discuss the complications that I did not take into account...
        Hide
        Martin Kouba
        added a comment -

        AFAIK EJB asynchronous methods do not propagate transaction context (see 4.5.3 Transactions in spec). Frankly speaking I can not imagine how this (any context propagation) could work and what benefits it would bring.

        As CDI 1.1 will surely have context lifecycle support there is a place for portable extensions to implement non-EJB async events (e.g. deltaspike module).

        So I don't think it's necessary to define asychronous events in the spec. Nevertheless I do vote for independent execution with no context propagation.

        Show
        Martin Kouba
        added a comment - AFAIK EJB asynchronous methods do not propagate transaction context (see 4.5.3 Transactions in spec). Frankly speaking I can not imagine how this (any context propagation) could work and what benefits it would bring. As CDI 1.1 will surely have context lifecycle support there is a place for portable extensions to implement non-EJB async events (e.g. deltaspike module). So I don't think it's necessary to define asychronous events in the spec. Nevertheless I do vote for independent execution with no context propagation.
        Hide
        Gerhard Petracek
        added a comment -

        based on deltaspike that's available since today ( see http://os890.blogspot.com/2013/05/async-cdi.html ) -> you can customize it easily (if you need more than what's available).

        Show
        Gerhard Petracek
        added a comment - based on deltaspike that's available since today ( see http://os890.blogspot.com/2013/05/async-cdi.html ) -> you can customize it easily (if you need more than what's available).
        Hide
        Martin Kouba
        added a comment -

        Gerhard, I don't think your AsyncInterceptor impl is quite correct and portable. Firstly the interceptors spec states: "Around-invoke and around-timeout interceptor methods run in the same Java thread as the associated target method.". So if there's some associated interceptor to be invoked after AsyncInterceptor this spec rule is violated. Furthermore I don't think it's legal/portable to invoke InvocationContext.proceed() in a different thread...

        Show
        Martin Kouba
        added a comment - Gerhard, I don't think your AsyncInterceptor impl is quite correct and portable. Firstly the interceptors spec states: "Around-invoke and around-timeout interceptor methods run in the same Java thread as the associated target method.". So if there's some associated interceptor to be invoked after AsyncInterceptor this spec rule is violated. Furthermore I don't think it's legal/portable to invoke InvocationContext.proceed() in a different thread...
        Hide
        Gerhard Petracek
        added a comment - - edited

        i haven't said that it is spec compliant or portable or supports every use-case. currently it only works with owb.

        Show
        Gerhard Petracek
        added a comment - - edited i haven't said that it is spec compliant or portable or supports every use-case. currently it only works with owb.

          People

          • Assignee:
            Unassigned
            Reporter:
            Nicklas Karlsson
          • Votes:
            7 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated: