[cdi-dev] Async events. We need ideas to improve CDI-499

[Mark Struberg]

purely technically: How do you manage to not spawn a new thread if you don't like to wait for the task to complete?

Wonder how that would work...

LieGrue,
strub




> On Tuesday, 10 February 2015, 10:50, Jozef Hartinger <jharting at redhat.com> wrote:
> > Async is not about a parallel thread. It is about fire() not waiting 
> until an observer finishes. Transactional observers are async already. 
> No need to make things more complicated by involving a "parallel 
> thread".
> 
> 
> On 02/10/2015 10:42 AM, Mark Struberg wrote:
>>  No they are not async in the sense that they get executed in a parallel 
> thread. That simply won't work. Think about 
> TransactionPhase.BEFORE_COMPLETION.
>>  There is a huge difference between 'it will get called on the same 
> thread but I have no control _when_' and 'it will get called on a 
> totally new thread'-
>> 
>>  For the TransactionPhase it is the first case imo.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>>  On Tuesday, 10 February 2015, 10:30, Jozef Hartinger 
> <jharting at redhat.com> wrote:
>>>>  T ransactional observers are by definition async so they should 
> behave
>>>  the same no matter if fired with fire() or fireAsync().
>>> 
>>> 
>>>  On 02/10/2015 09:13 AM, Mark Struberg wrote:
>>>>    Oh one more thing I found which is most probably broken or 
> totally changes
>>>  the behaviour
>>>>    8.) All observers with transactionPhase != IN_PROGRESS
>>>> 
>>>>    LieGrue,
>>>>    strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>    On Tuesday, 10 February 2015, 8:58, Mark Struberg
>>>  <struberg at yahoo.de> wrote:
>>>>>>    Hi José!
>>>>>    Backward compatibility is perfectly fine with both 
> approaches. People
>>>  can use
>>>>>    BeanManager#fire() instead of the newly proposed
>>>  BeanManager#fireAsync().
>>>>> 
>>>>>    My point is that many people will simply not be able to use 
> fireAsync()
>>>  because
>>>>>    as a framework developer you really need to code defensive. 
> Without an
>>>  explicit
>>>>>    opt-in on observer side fireAsync() can basically only be 
> used in
>>>  situations
>>>>>    where you _exactly_ know all your observers...
>>>>> 
>>>>>    An No @Async annotation would also be nice as it could not 
> only be
>>>  used at
>>>>>    @Observes but also for @Event
>>>>> 
>>>>>    @Inject
>>>>>    @Async
>>>>> 
>>>>>    @Event
>>>>> 
>>>>>    private Event<UserLoggedIn> userLoggedInEventSource;
>>>>> 
>>>>> 
>>>>>    The benefit of an own @Async annotation over extending e.g. 
> the @Event
>>>>>    annotation is that it would be perfectly backward compatible. 
> This code
>>>  would
>>>>>    also run on CDI-1.0 .. 1.2 containers (as all annotations 
> which are not
>>>>>    available on the classpath will simply be ignored by the JVM.
>>>>> 
>>>>>    LieGrue,
>>>>>    strub
>>>>> 
>>>>    _______________________________________________
>>>>    cdi-dev mailing list
>>>>   cdi-dev at lists.jboss.org
>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>    Note that for all code provided on this list, the provider 
> licenses the
>>>  code under the Apache License, Version 2
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided
>>>  on this list, the provider waives all patent and other intellectual 
> property
>>>  rights inherent in such information.
>>> 
>