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

Mark Struberg struberg at yahoo.de
Thu Feb 19 12:48:10 EST 2015


Hi Sven!

I don’t get the comparison with the Session. Attributes stored in the Session can get modified in parallel Servlet Requests since day 1 of the Servet specification. They also effectively almost always get handled by a different Thread for each subsequent Request. So thise objects must implement proper concurrency handling since forever. This is not changed by the fact that a lot of developers seem to not be aware of it.

LieGrue,
strub


> Am 19.02.2015 um 18:13 schrieb Sven Linstaedt <sven.linstaedt at gmail.com>:
> 
> 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 at gmail.com>:
> @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 at yahoo.de>:
> > 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.
> 




More information about the cdi-dev mailing list