<div dir="ltr">Hi,<br><br>and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions:<br><br>1. Regarding threading the current spec only states that "A context may be associated with one or more threads".<br><br>2. It is nowhere stated that @<span class="" id=":1tg.1" tabindex="-1">RequestScoped</span> beans are inherently thread safe. Thread safety was implied from the <span class="" id=":1tg.2" tabindex="-1">servlet</span> spec, because the scope backing container (<span class="" id=":1tg.3" tabindex="-1">ServletRequest</span>#attributes) was executed single threaded.<br><br>3. With <span class="" id=":1tg.4" tabindex="-1">Servlet</span> 3.0 the same <span class="" id=":1tg.5" tabindex="-1">ServletRequest</span>#attributes is available for access from multiple threads via <span class="" id=":1tg.6" tabindex="-1">ServletRequest</span>#<span class="" id=":1tg.7" tabindex="-1">startAsync</span>(), so containing objects may have a need for synchronization.<br><br>4. Why does <span class="" id=":1tg.8" tabindex="-1">CDI</span> 2.0 has to care about thread safety of @<span class="" id=":1tg.9" tabindex="-1">RequestScoped</span> beans? If the application is for some reason setting the request in async mode, the application must also ensure, it's containing and accessed beans are thread safe.<br><br><br>Best regards<br>Sven</div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I'm +1 for it but it needs important changes (= surely new contexts).<br>
Typically we can't change today @RequestScoped (which has no link with<br>
a request but only with a thread!).<br>
<br>
So we could have @RequestScoped (~ @ThreadLocalScoped) and<br>
@InheritedRequestScoped which would be a real request scope (but not<br>
an InheritedThreadLocal please)<br>
<br>
For the request it makes a lot of sense since you need to stay thread<br>
safe even accross threads (servlet spec) and avoids to be forced to<br>
use message passing which - even if a good pattern - adds boilerplate<br>
code for simple async needs.<br>
<br>
For JAXRS I dont know since it is really suspend/resume semantic so<br>
request scope maybe doesnt makes much sense here (there is a break in<br>
the flow).<br>
<br>
<br>
<br>
Romain Manni-Bucau<br>
@rmannibucau<br>
<a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
<a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
<a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
<div><div class="h5"><br>
<br>
2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>>:<br>
> Hi All,<br>
><br>
> Beyond the asynchronous event case, shouldn’t we provide a way for user to launch async treatments in CDI with the possibility to keep the existing contexts at the moment of async operation launch?<br>
> Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn’t we think to something like that?<br>
><br>
> Thanks for your input on that point.<br>
><br>
> Antoine<br>
><br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</blockquote></div><br></div>