Hi,
On Sat, Mar 19, 2016 at 10:02 PM, Stephan Knitelius <stephan(a)knitelius.com>
wrote:
Well as discussed in another mail, the concurrency spec is a bit
ambiguous
about context propagation, it's not explicitly forbidden.
Would a new context also belong into the concurrency spec?
I think so. Such context is intended for concurrency (threading), and
there's a strong precedent for that the spec that owns a concept defines
the context. E.g. JTA defines the @Transactional context, JSF the
@FlowScoped one, MVC @RedirectScoped, etc.
Kind regards,
Arjan Tijms
On Sa., 19. März 2016 at 21:57, arjan tijms <arjan.tijms(a)gmail.com> wrote:
> Hi,
>
> On Saturday, March 19, 2016, 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.
>
>
> That really sounds like a very useful proposal. Kinda like a session
> scope, but for a select group of threads.
>
> Like so many other things, logically you'd say such thing should be
> placed in the concurrency spec. Feels weird to put things in another less
> logical place just because there are no plans do a concurrency spec update.
>
> Kind regards,
> Arjan Tijms
>
>
>
>>
>> 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> 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>:
>>> >
>>> > 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>
>>> 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>:
>>> >>>
>>> >>> 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>:
>>> >>> 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>:
>>> >>>>
>>> >>>> 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
>>> >>>>
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.
>>> >
>>> > _______________________________________________
>>> > 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.
>>
>>