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

[Sven Linstaedt]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150219/338db529/attachment-0001.html