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

Jozef Hartinger jharting at redhat.com
Tue Feb 10 04:50:47 EST 2015


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.
>>



More information about the cdi-dev mailing list