[cdi-dev] Async events. We need ideas to improve CDI-499
Antoine Sabot-Durand
antoine at sabot-durand.net
Mon Feb 9 12:28:55 EST 2015
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
More information about the cdi-dev
mailing list