10:30 a.m.
Right, these usecases won't work together with async delivery. In an
ideal world an event payload would contain all the state possibly needed
by an observer and the payload would be documented to be fired async. In
an ideal world users would not rely on any of those bullets you wrote as
they would understand async. Same as you would not use of those bullets
in MDB's onReceive(), @Asynchronous method or Akka actor's receive(). Or
would you? Now obviously that is an ideal world far from the real one in
which this is a risk.
On the other hand, the "async switch on both sides" option, which you
prefer, is a huge barrier to adoption.
Seems that we currently have two options out of which none is a good one.
On 02/09/2015 11:12 AM, Mark Struberg wrote:
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.
>
>