[cdi-dev] @ThreadScoped?

Sat Mar 19 17:02:43 EDT 2016

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?
On Sa., 19. März 2016 at 21:57, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> On Saturday, March 19, 2016, 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.
>
>
> 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 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.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/6ff1f828/attachment.html 