I guess 2 is not a real need - and at least not why people voted for
this feature. Difference between fireAsync and @Async is who decides
to be asynchronous. Caller (fire) should clearly be able IMO - with
all the warning we can put in the spec to say it should be done with
compatible scopes. The second one is less important for me cause you
can already do it with concurrency utilities (ee one or not) pretty
easily.
Romain Manni-Bucau
@rmannibucau
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(a)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(a)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(a)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(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.
>>>>>>
>>>>>>
>>>>
>>
>>
>> _______________________________________________
>> 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.