Re: [cdi-dev] Enhancing SPI to support async operation for contexts

Am 19.02.2015 um 18:13 schrieb Sven Linstaedt <sven.linstaedt(a)gmail.com&gt;: 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? 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. 2015-02-19 17:52 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: @Mark: for the container usage only but nothing prevents you to use it elsewhere at your own risk Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 17:40 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: > Even in Servlets-3.0 a ‚Request‘ is only attached to exactly one single thread AT THE SAME TIME afaik. > > 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. > > LieGrue, > strub > > >> Am 19.02.2015 um 17:33 schrieb Sven Linstaedt <sven.linstaedt(a)gmail.com&gt;: >> >> Hi, >> >> and sorry for spontaneously dropping in. Just to clarify some personal questions/assumptions: >> >> 1. Regarding threading the current spec only states that "A context may be associated with one or more threads". >> >> 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. >> >> 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. >> >> 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. >> >> >> Best regards >> Sven >> >> 2015-02-19 11:22 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: >> Hi >> >> I'm +1 for it but it needs important changes (= surely new contexts). >> Typically we can't change today @RequestScoped (which has no link with >> a request but only with a thread!). >> >> So we could have @RequestScoped (~ @ThreadLocalScoped) and >> @InheritedRequestScoped which would be a real request scope (but not >> an InheritedThreadLocal please) >> >> For the request it makes a lot of sense since you need to stay thread >> safe even accross threads (servlet spec) and avoids to be forced to >> use message passing which - even if a good pattern - adds boilerplate >> code for simple async needs. >> >> For JAXRS I dont know since it is really suspend/resume semantic so >> request scope maybe doesnt makes much sense here (there is a break in >> the flow). >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-02-19 10:32 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: >> > Hi All, >> > >> > 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? >> > Today servlet or JAX-RS spec support async call without the loss of request for instance. Shouldn’t we think to something like that? >> > >> > Thanks for your input on that point. >> > >> > 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. _______________________________________________ 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.