[cdi-dev] @ThreadScoped?
Romain Manni-Bucau
rmannibucau at gmail.com
Sun Mar 20 16:34:39 EDT 2016
Le 20 mars 2016 21:28, "Mark Struberg" <struberg at yahoo.de> a écrit :
>
> I'd say we could move a request context from EXCLUSIVE threadA to
EXCLUSIVE threadA.
>
> But we cannot make the same request scoped Bean accessible from multiple
Threads at the same time.
>
+1 for it
> Lgm
>
>
> --------------------------------------------
> On Sun, 20/3/16, Manfred Riem <mnriem at gmail.com> wrote:
>
> Subject: Re: [cdi-dev] @ThreadScoped?
> To: "Stephan Knitelius" <stephan at knitelius.com>
> Cc: "Mark Struberg" <struberg at yahoo.de>, "Reza Rahman" <
reza_rahman at lycos.com>, "cdi-dev" <cdi-dev at lists.jboss.org>
> Date: Sunday, 20 March, 2016, 18:36
>
> Why is changing
> @RequestScoped out of the question?
>
> From my perspective when an AsyncContext is
> started the request is still there.
>
> It is just being served by a different
> thread.
>
> Certainly there is
> a need to work with the Servlet EG to figure out how to
> transfer “ownership” to the AsyncContext.
>
> Anyway my 2 cents
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
> > On Mar 19, 2016, at 3:35
> PM, Stephan Knitelius <stephan at knitelius.com>
> wrote:
> >
> > 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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:cdi-dev at lists.jboss.org>
> > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> <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
> <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
> <mailto:cdi-dev at lists.jboss.org>
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> <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
> <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
> <mailto:cdi-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> <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
> <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
> <mailto:cdi-dev at lists.jboss.org>
> >
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> <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
> <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/20160320/33b3e542/attachment-0001.html
More information about the cdi-dev
mailing list