But that might defeat pluggabilgity. Basically no framework can use fireAsync in that
case.
Imagine a UserLoggedIn event. For most observers it is perfectly fine to observe this in a
new thread. But some might need to access the session -> boom. Which means that all
frameworks have to fall back to the 'safe' fire() instead of fireAsync()...
That will leave us half-broken as it totally defeats the usage of this cool feature...
LieGrue,
strub
On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand
<antoine(a)sabot-durand.net> wrote:
> Mark,
During last meeting we didn’t say there wasn’t use case that would break
existing observer, we said that since we keep the current fire() method there is
backward compatibility. User trying to send fireAsync() and experiencing error
with legacy observer will have to fall back to fire().
Antoine
> Le 9 févr. 2015 à 11:12, Mark Struberg <struberg(a)yahoo.de> a écrit :
>
> Hi Jozef, here we go!
>
>
> 1.) accessing @RequestScoped beans in your Observer
>
> 2.) accessing @SessionScoped beans in your Observer
> 3.) accessing/relying on any transactional behaviour. This is really a
boomer. Basically you break transactions that way.
>
> 4.) accessing @TransactionScoped beans in your Observer
>
> 5.) access/relying on any ThreadLocal in your Observer
> 6.) accessing attached entities in your Observers (they must only get
accessed from a very single Thread according to the JPA spec)
> 7.) using an EntityManager in a parallel thread might give you unexpected
results.
>
>
> There might be quite a few more. E.g. we need to specify that EJBs and
other EE features need to work in such a new Thread, etc
>
>
> LieGrue,
> strub
>
>
> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger
<jharting(a)redhat.com> wrote:
>
>
>>
>>
>> We should enumerate all the arguments supporting async flag on an
observer. So far I have only seen one:
>>
>> - an observer accessing @RequestScoped state would no longer be able
> to do so since it would be run in a worker thread
>>
>> I am eager to hear more arguments as this single one may not be
> enough to justify the observer-async-flag design decision.
>>
>> Remember that introducing fireAsync() itself does not break any
> existing application because existing applications are using fire().
> It's when an existing application / library is modified to use
> fireAsync() when the problem may occur. Such change should not be
> done blindly. As with any other change, an author should consider
> possible consequences of the change. Clearly documenting the fact
> that fireAsync() processing is done in a different thread with a
> different @RequestScoped state may be sufficient.
>>
>> Jozef
>>
>>
>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote:
>>
>> Hi all,
>>>
>>>
>>>
>>>
>>>
https://issues.jboss.org/browse/CDI-499 comes after a lot of
discussion about async events.
>>>
>>>
>>> I think the solution exposed here is quite satisfying, yet the idea
to need to activate async behaviour on the observer side doesn’t please a lot of
us. It’ll be confusing for users to have to activate async from the firing end
and consuming end to see it work :-(.
>>>
>>>
>>> I’d like to see alternative proposal to have this new feature as
user friendly as possible and keep the retro-compatibility aspect. We should
find a better solution on our next meeting on wednesday.
>>>
>>>
>>> Antoine
>>>
>>>
>>> _______________________________________________
> 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.
>>
>>