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

Mark Struberg struberg at yahoo.de
Thu Feb 19 11:40:34 EST 2015


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.




More information about the cdi-dev mailing list