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

Mark Struberg struberg at yahoo.de
Mon Feb 9 14:33:21 EST 2015 

Btw, did we already cover the 'fireAndForget' vs 'fireAndWait' use cases?

1. fireAndForget: this is basically what you get today if you use @javax.ejb.Asynchronous on an @Observer method

2.) fireAndWait: call all observers in a new thread and only return after all observer methods did finish.



Did we already agree on one of the 2 modi? If not, do we like to support both? And if so, how to tell the CDI container which of the 2 modes to use for each observer?


If you answer the last question with yes then we might need some annotation/additional info on the observer method anyway. And then we are back on our @Async annotation on the observer method...


LieGrue,
strub


On Monday, 9 February 2015, 18:43, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>Guys I'm not sure to fully get the jira description now. Can you try
>to rephrase it a bit?
>
>Here what I see:
>
>1) fireAsync (+1) is clear
>2) (part I dont fully get) asyncSupported: is it mandatory? If yes I
>think this API is not usable (=user friendly) and I would just suggest
>it is on by default and to remove this flag
>
>
>Can it break apps? Yes as mentionned by Mark. Will it break apps? No
>since it is not yet used and this is surely what we want. I fully
>understand all the mentionned pitfalls - but let me say @RequestScoped
>is by definition as broken as this today since you can't associate it
>with a request for the exact same reason. What I mean is: if you
>choose async then you assume it so I think we shouldn't protect the
>user from pitfalls then...in particular since we can't protect him
>from other as vicious issues.
>
>
>
>
>
>Romain Manni-Bucau
>@rmannibucau
>http://www.tomitribe.com
>http://rmannibucau.wordpress.com
>https://github.com/rmannibucau
>
>
>2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:
>> 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.
>>>>>>
>>>>>>
>>>>
>>
>>
>> _______________________________________________
>> 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.
>
>

More information about the cdi-dev mailing list