[cdi-dev] @ThreadScoped?

Sat Mar 19 16:35:29 EDT 2016

I would certainly agree with the assertion that in general it's not
advisable to execute a request with multiple threads and that usually
single threaded execution is sufficient.

However I don't think ignoring it is an option. Concurrent operations can
be launched even from CDI beans. Yet we don't properly support context
propagation nor a context spanning all threads launched from a request.

I know that changing @requestScoped is probably out of the question, but at
least we should consider adding a new context spanning all threads and
defining a logical solution for context propagation that can be explained
to the end user.

On Fr., 11. März 2016 at 17:17, Mark Struberg <struberg at yahoo.de> wrote:

> Yes, but certain things in EE are assumed to be handled on a single
> thread. And if you run on a servr then this is really not a blocker most
> times. If I get many paralllel requests hitting my box then I do not need
> async handling _that_ often. The whole overhead for setting up the new
> thread, etc often heavily exceeds the benefits.
> So I would not put too much energy into it…
>
> LieGrue,
> strub
>
> > Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman at lycos.com>:
> >
> > This is essentially in keeping with the minimalist nature of the EE
> concurrency JSR. I believe most of it is left to vendors to do the right
> thing for users. May be a good idea is this language can be tightened up.
> >
> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg <struberg at yahoo.de> wrote:
> >> E
> >> From the servlet spec:
> >>
> >> „Java Enterprise Edition features such as Section 15.2.2, “Web
> Application Environment” on page 15-174 and Section 15.3.1, “Propagation of
> Security Identity in EJBTM Calls” on page 15-176 are available only to
> threads executing the initial request or when the request is dispatched to
> the container via the AsyncContext.dispatch method. Java Enterprise Edition
> features may be available to other threads operating directly on the
> response object via the AsyncContext.start(Runnable) method.“
> >>
> >> check „available only to threads executing the initial request“
> >>
> >> Also if you look at the servlet AsyncContext then all the wording is
> written as MAY and not as MUST.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau <
> rmannibucau at gmail.com>:
> >>>
> >>> Hi Mark,
> >>>
> >>> think 2.3.3.4 states the opposite.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>>
> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
> >>> Back from JavaLand conference, so sorry for not kicking in earlier.
> >>>
> >>> I not quite get the argumentation chain. It’s that all triggered by
> async servlet requests? And isn’t the servlet spec also saying that all the
> request param etc may max be assigned to a single thread AT A TIME!
> >>>
> >>> Means that it might not be on multiple threads in parallel, but the
> data is allowed to get moved from one thread to another (disapearing from
> the first one), right?
> >>> Would really need to dig into the wording of the async servlets spec
> again, maybe has this in the back of his head?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <
> rmannibucau at gmail.com>:
> >>>>
> >>>> Hi guys,
> >>>>
> >>>> following request scope thread and to center the discussion on the
> thread safety part: do we work on this?
> >>>>
> >>>> Background: @RequestScoped is often used as a ThreadLocal instance
> solution. A lot of SE or Batch implementations rely on it from what I saw
> as well as async implementations reusing existing business logic with this
> thread safety constraint.
> >>>>
> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI
> and implemenation and would avoid the headache we can have with
> @RequestScoped. Will also remove the quite dark side of the spec regarding
> servlet request and request scope since now we would have a more natural
> solution for all of these situation so @RequestScoped goals wouldn't
> collide as much.
> >>>>
> >>>> Questions:
> >>>> - is it automatically started as request scoped is (JMS, @Async,
> ...)? Alternative could be some configuration in beans.xml (merged accross
> the app):
> >>>>
> >>>> <beans>
> >>>> <scopes>
> >>>>   <thread>
> >>>>     <active>JMS</active>
> >>>>     <active>ASYNCHONOUS</active>
> >>>>   </thread>
> >>>> </scopes>
> >>>> </beans>
> >>>>
> >>>> - start/stop API (this is typically an API the user should be able to
> control for its own threads)
> >>>> - CDI 2.*0*?
> >>>>
> >>>> wdyt?
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>>> _______________________________________________
> >>>> 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/20160319/1e3adce7/attachment-0001.html 