[cdi-dev] @ThreadScoped?

Sat Mar 19 17:37:35 EDT 2016

Hi,

On Sat, Mar 19, 2016 at 10:02 PM, Stephan Knitelius <stephan at 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 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/6e1d411f/attachment.html 