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