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

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&gt; wrote: to do so since it would be run in a worker thread enough to justify the observer-async-flag design decision. 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. 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.