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

[Antoine Sabot-Durand]

Mark I understand your concern, now can you understand the one we discussed about the fact of having to enable async at both ends is a source of confusion for end users and will give a bad perception of the spec.

So could we figure something user friendly to enable async event?

Antoine


> Le 9 févr. 2015 à 12:00, Mark Struberg <struberg at yahoo.de> a écrit :
> 
> 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.
>>>> 
>>>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150209/21af0962/attachment.bin