[cdi-dev] @ThreadScoped?
Mark Struberg
struberg at yahoo.de
Sun Mar 20 16:25:31 EDT 2016
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.
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.
More information about the cdi-dev
mailing list