<p dir="ltr"><br>
Le 20 mars 2016 21:28, "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> a écrit :<br>
><br>
> I'd say we could move a request context from EXCLUSIVE threadA to EXCLUSIVE threadA.<br>
><br>
> But we cannot make the same request scoped Bean accessible from multiple Threads at the same time.<br>
><br></p>
<p dir="ltr">+1 for it</p>
<p dir="ltr">> Lgm<br>
><br>
><br>
> --------------------------------------------<br>
> On Sun, 20/3/16, Manfred Riem <<a href="mailto:mnriem@gmail.com">mnriem@gmail.com</a>> wrote:<br>
><br>
> Subject: Re: [cdi-dev] @ThreadScoped?<br>
> To: "Stephan Knitelius" <<a href="mailto:stephan@knitelius.com">stephan@knitelius.com</a>><br>
> Cc: "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>, "Reza Rahman" <<a href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>>, "cdi-dev" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> Date: Sunday, 20 March, 2016, 18:36<br>
><br>
> Why is changing<br>
> @RequestScoped out of the question?<br>
><br>
> From my perspective when an AsyncContext is<br>
> started the request is still there.<br>
><br>
> It is just being served by a different<br>
> thread.<br>
><br>
> Certainly there is<br>
> a need to work with the Servlet EG to figure out how to<br>
> transfer “ownership” to the AsyncContext.<br>
><br>
> Anyway my 2 cents<br>
><br>
> Thanks!<br>
><br>
> Kind regards,<br>
> Manfred Riem<br>
><br>
> > On Mar 19, 2016, at 3:35<br>
> PM, Stephan Knitelius <<a href="mailto:stephan@knitelius.com">stephan@knitelius.com</a>><br>
> wrote:<br>
> ><br>
> > I would<br>
> certainly agree with the assertion that in general it's<br>
> not advisable to execute a request with multiple threads and<br>
> that usually single threaded execution is sufficient.<br>
> ><br>
> > However I don't<br>
> think ignoring it is an option. Concurrent operations can be<br>
> launched even from CDI beans. Yet we don't properly<br>
> support context propagation nor a context spanning all<br>
> threads launched from a request.<br>
> ><br>
> > I know that changing @requestScoped is<br>
> probably out of the question, but at least we should<br>
> consider adding a new context spanning all threads and<br>
> defining a logical solution for context propagation that can<br>
> be explained to the end user.<br>
> ><br>
> ><br>
> ><br>
> > On Fr., 11. März 2016 at 17:17, Mark<br>
> Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a><br>
> <mailto:<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>><br>
> wrote:<br>
> > Yes, but certain things in EE<br>
> are assumed to be handled on a single thread. And if you run<br>
> on a servr then this is really not a blocker most times. If<br>
> I get many paralllel requests hitting my box then I do not<br>
> need async handling _that_ often. The whole overhead for<br>
> setting up the new thread, etc often heavily exceeds the<br>
> benefits.<br>
> > So I would not put too much<br>
> energy into it…<br>
> ><br>
> ><br>
> LieGrue,<br>
> > strub<br>
> ><br>
> > > Am 11.03.2016 um 15:44 schrieb Reza<br>
> Rahman <<a href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a><br>
> <mailto:<a href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>>>:<br>
> > ><br>
> > > This is<br>
> essentially in keeping with the minimalist nature of the EE<br>
> concurrency JSR. I believe most of it is left to vendors to<br>
> do the right thing for users. May be a good idea is this<br>
> language can be tightened up.<br>
> > ><br>
> > >> On Mar 11, 2016, at 6:01 AM, Mark<br>
> Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a><br>
> <mailto:<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>><br>
> wrote:<br>
> > >> E<br>
> ><br>
> >> From the servlet spec:<br>
> ><br>
> >><br>
> > >> „Java Enterprise<br>
> Edition features such as Section 15.2.2, “Web Application<br>
> Environment” on page 15-174 and Section 15.3.1,<br>
> “Propagation of Security Identity in EJBTM Calls” on<br>
> page 15-176 are available only to threads executing the<br>
> initial request or when the request is dispatched to the<br>
> container via the AsyncContext.dispatch method. Java<br>
> Enterprise Edition features may be available to other<br>
> threads operating directly on the response object via the<br>
> AsyncContext.start(Runnable) method.“<br>
> ><br>
> >><br>
> > >> check „available<br>
> only to threads executing the initial request“<br>
> > >><br>
> > >><br>
> Also if you look at the servlet AsyncContext then all the<br>
> wording is written as MAY and not as MUST.<br>
> > >><br>
> > >><br>
> LieGrue,<br>
> > >> strub<br>
> > >><br>
> > >><br>
> > >>> Am 10.03.2016 um 19:52<br>
> schrieb Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a><br>
> <mailto:<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>>:<br>
> > >>><br>
> ><br>
> >>> Hi Mark,<br>
> > >>><br>
> > >>> think 2.3.3.4 states the<br>
> opposite.<br>
> > >>><br>
> > >>><br>
> ><br>
> >>> Romain Manni-Bucau<br>
> ><br>
> >>> @rmannibucau | Blog | Github | LinkedIn |<br>
> Tomitriber<br>
> > >>><br>
> > >>> 2016-03-10 19:43 GMT+01:00<br>
> Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a><br>
> <mailto:<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>>:<br>
> > >>> Back from JavaLand<br>
> conference, so sorry for not kicking in earlier.<br>
> > >>><br>
> ><br>
> >>> I not quite get the argumentation chain. It’s<br>
> that all triggered by async servlet requests? And isn’t<br>
> the servlet spec also saying that all the request param etc<br>
> may max be assigned to a single thread AT A TIME!<br>
> > >>><br>
> ><br>
> >>> Means that it might not be on multiple threads<br>
> in parallel, but the data is allowed to get moved from one<br>
> thread to another (disapearing from the first one),<br>
> right?<br>
> > >>> Would really need<br>
> to dig into the wording of the async servlets spec again,<br>
> maybe has this in the back of his head?<br>
> ><br>
> >>><br>
> > >>> LieGrue,<br>
> > >>> strub<br>
> ><br>
> >>><br>
> > >>><br>
> > >>><br>
> ><br>
> >>><br>
> > >>>> Am<br>
> 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a><br>
> <mailto:<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>>:<br>
> > >>>><br>
> ><br>
> >>>> Hi guys,<br>
> ><br>
> >>>><br>
> > >>>><br>
> following request scope thread and to center the discussion<br>
> on the thread safety part: do we work on this?<br>
> > >>>><br>
> ><br>
> >>>> Background: @RequestScoped is often used as<br>
> a ThreadLocal instance solution. A lot of SE or Batch<br>
> implementations rely on it from what I saw as well as async<br>
> implementations reusing existing business logic with this<br>
> thread safety constraint.<br>
> ><br>
> >>>><br>
> > >>>><br>
> Proposal: providing a @ThreadScoped implementation is cheap<br>
> for CDI and implemenation and would avoid the headache we<br>
> can have with @RequestScoped. Will also remove the quite<br>
> dark side of the spec regarding servlet request and request<br>
> scope since now we would have a more natural solution for<br>
> all of these situation so @RequestScoped goals wouldn't<br>
> collide as much.<br>
> > >>>><br>
> > >>>> Questions:<br>
> > >>>> - is it automatically<br>
> started as request scoped is (JMS, @Async, ...)? Alternative<br>
> could be some configuration in beans.xml (merged accross the<br>
> app):<br>
> > >>>><br>
> > >>>> <beans><br>
> > >>>> <scopes><br>
> ><br>
> >>>> <thread><br>
> > >>>> <br>
> <active>JMS</active><br>
> > >>>> <br>
> <active>ASYNCHONOUS</active><br>
> ><br>
> >>>> </thread><br>
> > >>>> </scopes><br>
> > >>>> </beans><br>
> > >>>><br>
> ><br>
> >>>> - start/stop API (this is typically an API<br>
> the user should be able to control for its own threads)<br>
> > >>>> - CDI 2.*0*?<br>
> > >>>><br>
> ><br>
> >>>> wdyt?<br>
> ><br>
> >>>><br>
> > >>>><br>
> Romain Manni-Bucau<br>
> > >>>><br>
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber<br>
> > >>>><br>
> _______________________________________________<br>
> > >>>> cdi-dev mailing list<br>
> > >>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > >>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>><br>
> > >>>><br>
> ><br>
> >>>> Note that for all code provided on this<br>
> list, the provider licenses the code under the Apache<br>
> License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>>).<br>
> For all other ideas provided on this list, the provider<br>
> waives all patent and other intellectual property rights<br>
> inherent in such information.<br>
> ><br>
> >>><br>
> > >>><br>
> > >><br>
> > >><br>
> > >><br>
> _______________________________________________<br>
> > >> cdi-dev mailing list<br>
> > >> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > >> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>><br>
> > >><br>
> > >><br>
> Note that for all code provided on this list, the provider<br>
> licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>>).<br>
> For all other ideas provided on this list, the provider<br>
> waives all patent and other intellectual property rights<br>
> inherent in such information.<br>
> > ><br>
> > ><br>
> _______________________________________________<br>
> > > cdi-dev mailing list<br>
> > > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>><br>
> > ><br>
> > > Note that<br>
> for all code provided on this list, the provider licenses<br>
> the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>>).<br>
> For all other ideas provided on this list, the provider<br>
> waives all patent and other intellectual property rights<br>
> inherent in such information.<br>
> ><br>
> ><br>
> ><br>
> _______________________________________________<br>
> > cdi-dev mailing list<br>
> ><br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> ><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>><br>
> ><br>
> > Note that for all<br>
> code provided on this list, the provider licenses the code<br>
> under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a><br>
> <<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>>).<br>
> For all other ideas provided on this list, the provider<br>
> waives all patent and other intellectual property rights<br>
> inherent in such information.<br>
> ><br>
> _______________________________________________<br>
> > cdi-dev mailing list<br>
> ><br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all<br>
> code provided on this list, the provider licenses the code<br>
> under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas provided on this list, the provider<br>
> waives all patent and other intellectual property rights<br>
> inherent in such information.<br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</p>