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

[Jozef Hartinger]

The way transactional observers are defined is that the observer method 
is not called right away within the fire() call but instead is scheduled 
to be executed in the corresponding transaction phase (e.g. using JTA's 
Synchronization). This allows the fire() call to exit without waiting 
for the observer to complete. Therefore, the transactional observer 
notification is asynchronous. This has been the case since CDI 1.0 and 
OWB should implement it that way too!

On 02/10/2015 10:53 AM, Mark Struberg wrote:
> 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.
>>>>