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

[Antoine Sabot-Durand]

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.