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(a)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(a)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(a)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(a)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(a)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(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.
_______________________________________________
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.