3:25 p.m.
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(a)gmail.com> wrote:
Subject: Re: [cdi-dev] @ThreadScoped?
To: "Stephan Knitelius" <stephan(a)knitelius.com>
Cc: "Mark Struberg" <struberg(a)yahoo.de>, "Reza Rahman"
<reza_rahman(a)lycos.com>, "cdi-dev" <cdi-dev(a)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
LieGrue,
> 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(a)yahoo.de
<mailto:struberg@yahoo.de>>
wrote:
>>>> wdyt?
>>>> 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.
>>>
> >>>
>
_______________________________________________
> 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.
>
_______________________________________________
https://lists.jboss.org/mailman/listinfo/cdi-dev
<https://lists.jboss.org/mailman/listinfo/cdi-dev>
_______________________________________________
On Mar 19, 2016, at 3:35
PM, Stephan Knitelius
<stephan(a)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(a)yahoo.de
<mailto:struberg@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…
strub
> Am 11.03.2016 um 15:44 schrieb Reza
Rahman <reza_rahman(a)lycos.com
<mailto:reza_rahman@lycos.com>>:
>> 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(a)gmail.com
<mailto:rmannibucau@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(a)yahoo.de
<mailto:struberg@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(a)gmail.com
<mailto:rmannibucau@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*?
>>>>
>>>
>>>>
Romain Manni-Bucau
>>>>
@rmannibucau | Blog | Github | LinkedIn |
Tomitriber
>>>>
_______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
<https://lists.jboss.org/mailman/listinfo/cdi-dev>
>>>>
>>
>>
> >>
_______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
<mailto:cdi-dev@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
<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(a)lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
<https://lists.jboss.org/mailman/listinfo/cdi-dev>
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
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(a)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.
3:34 p.m.
New subject: @ThreadScoped?
Le 20 mars 2016 21:28, "Mark Struberg" <struberg(a)yahoo.de> a écrit :
+1 for it
> Lgm
>
--------------------------------------------
> On Sun, 20/3/16, Manfred Riem <mnriem(a)gmail.com> wrote:
> Subject: Re: [cdi-dev] @ThreadScoped?
> To: "Stephan Knitelius" <stephan(a)knitelius.com > Cc: "Mark Struberg" <struberg(a)yahoo.de>,
"Reza Rahman" <
reza_rahman(a)lycos.com>, "cdi-dev" <cdi-dev(a)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(a)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(a)yahoo.de
> <mailto:struberg@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(a)lycos.com
> <mailto:reza_rahman@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(a)yahoo.de
> <mailto:struberg@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(a)gmail.com
> <mailto:rmannibucau@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(a)yahoo.de
> <mailto:struberg@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(a)gmail.com
> <mailto:rmannibucau@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(a)lists.jboss.org
> <mailto:cdi-dev@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(a)lists.jboss.org
> <mailto:cdi-dev@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(a)lists.jboss.org
> <mailto:cdi-dev@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(a)lists.jboss.org
> <mailto:cdi-dev@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(a)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(a)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.
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.
3198
days inactive
3198
days old
1 comments
2 participants
participants (2)
-
Mark Struberg -
Romain Manni-Bucau