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

Mark Struberg struberg at yahoo.de
Wed Feb 11 04:32:30 EST 2015 

Not quite sure about this. Indeed CDI doesn't specify anything in this regard. But the JPA and JTA specs clearly do specify that their handling need to be defined on the same thread. So it's kind of implicitly defined by those specs I'd say. 


LieGrue,
strub




> On Wednesday, 11 February 2015, 9:59, Jozef Hartinger <jharting at redhat.com> wrote:
> > 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.
> 
> _______________________________________________
> 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