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

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)yahoo.de&gt; 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(a)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(a)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.