<div dir="ltr">The question remains: Does CDI has to make sure, request scope implies single threaded access, because most existing applications are not aware of possible threading issues for request scoped beans? <div><br></div><div>I do not think so. Afaik the same problem has affected session scoped beans before servlet 3.0, but application developers are hopefully more aware of it.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-19 17:52 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">@Mark: for the container usage only but nothing prevents you to use it<br>
elsewhere at your own risk<br>
<span class="im HOEnZb"><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>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">2015-02-19 17:40 GMT+01:00 Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>:<br>
> Even in Servlets-3.0 a ‚Request‘ is only attached to exactly one single thread AT THE SAME TIME afaik.<br>
><br>
> So they can switch a Request from one thread to another one, but there is always just a single one accessing it at the same time. At least that is what I did understand.<br>
><br>
> LieGrue,<br>
> strub<br>
><br>
><br>
>> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt <<a href="mailto:sven.linstaedt@gmail.com">sven.linstaedt@gmail.com</a>>:<br>
>><br>
>> 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 @RequestScoped beans are inherently thread safe. Thread safety was implied from the servlet spec, because the scope backing container (ServletRequest#attributes) was executed single threaded.<br>
>><br>
>> 3. With Servlet 3.0 the same ServletRequest#attributes is available for access from multiple threads via ServletRequest#startAsync(), so containing objects may have a need for synchronization.<br>
>><br>
>> 4. Why does CDI 2.0 has to care about thread safety of @RequestScoped 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<br>
>><br>
>> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
>> 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>
>><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>
>> > _______________________________________________<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.<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.<br>
><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.<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.</div></div></blockquote></div><br></div>