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.

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.

@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 >: >> >> 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.

today request scope = thread scope and we can't help on it. I recall having said web scopes should stay aligned on web behavior but answer was quite clear: this is not what is in the spec (at least in intention term) which is fine but today request scope is also used in batches for thread scope behaviors so too late to change. Servlet spec can have its own web scope now which would allow to fix this and go ahead. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-02-19 18:13 GMT+01:00 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 >: >> >> 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. > >

> Okay, so request scope is not associated with web requests, but with „invocation chains". Yes. E.g. the Context for RequestScoped beans has to be active for invocations of @Asynchronous methods, MessageBean invocations, @PostConstruct and @PreDestroy methods of all Managed Beans, @WebService invocations, etc > whether session scope is propagated to newly spawned threads We can look at javax.ejb.Asynchronous. Invocations to those methods will get a new Request Context but there will be no SessionContext for them (which Session would you attach to this thread? It could also be a long-running one…). LieGrue, strub > Am 19.02.2015 um 18:44 schrieb Sven Linstaedt <sven.linstaedt(a)gmail.com&gt;: > > Okay, so request scope is not associated with web requests, but with "invocation chains". I thought so because session scope is associated with web requests and Weld is backing it's request scope implementation with request attributes. > > So the SPI has a need for dispatching async work in new threads, at it's best with most common scopes (application, session and request) being active? > > Application does not seem to be a problem. Request is always a new context per thread. The question is, whether session scope is propagated to newly spawned threads, when using this SPI? Afaik it's currently only active during web requests. From an implementation point of view it could be tricky to disassociate current session scope impls from servlet session lifecycle. On the other side: from a user point of view it would be nice, if I dispatch work via some SPI, the processing of work is done in the same "user context". > > > > 2015-02-19 18:18 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > today request scope = thread scope and we can't help on it. I recall > having said web scopes should stay aligned on web behavior but answer > was quite clear: this is not what is in the spec (at least in > intention term) which is fine but today request scope is also used in > batches for thread scope behaviors so too late to change. Servlet spec > can have its own web scope now which would allow to fix this and go > ahead. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-02-19 18:13 GMT+01:00 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. >> >> >

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.

I agree with Romain that we cannot change the semantics of existing contexts. Furthermore, I think that instead of these tricky context propagations we should promote async event-driven architecture where as much state as needed is carried within the message / event payload itself instead of clients relying on state from context, threadlocal, etc. Jozef On 02/19/2015 10:32 AM, Antoine Sabot-Durand wrote: > 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.