[cdi-dev] @ThreadScoped?

Sun Mar 20 15:47:38 EDT 2016

Le 20 mars 2016 20:40, "Mark Struberg" <struberg at yahoo.de> a écrit :
>
> A scope annotation cannot have a flag.
>

Why? Technically it can

> LieGrue,
> strub
>
>
>
>
> On Sunday, 20 March 2016, 20:25, Reza Rahman <reza_rahman at lycos.com>
wrote:
>
>
> >
> >
> >As discussed elsewhere in this EG, even in the most pessimistic reading
of the current spec, all that would be needed is a flag on the existing
annotation. It's not out of the question at all.
> >
> >On Mar 20, 2016, at 1:36 PM, Manfred Riem <mnriem at gmail.com> wrote:
> >
> >
> >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>
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.
> _______________________________________________
> >>>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/20160320/4c6fe50f/attachment-0001.html 