[cdi-dev] Async events. We need ideas to improve CDI-499
Mark Struberg
struberg at yahoo.de
Tue Feb 10 04:42:44 EST 2015
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