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

[Mark Struberg]

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 at 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 at 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 at 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 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.
>>> 
>>> 
>