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

[Jozef Hartinger]

Usually the observers are called from within the same thread as fire(). 
It may however not be the case always thus relying on modification of 
non-thread-safe payload is probably a bad idea.

On 02/10/2015 11:51 AM, Antoine Sabot-Durand wrote:
> Jozef,
>
> One question. So today we have an async behaviour with transactional observer. What about event payload modification in these observer ?
>
> Antoine Sabot-Durand
>
>
>> Le 10 févr. 2015 à 11:40, Jozef Hartinger <jharting at redhat.com> a écrit :
>>
>> 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.
>>>>>>
>> _______________________________________________
>> 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.