[cdi-dev] @ThreadScoped?

Romain Manni-Bucau rmannibucau at gmail.com
Tue Mar 8 09:18:02 EST 2016


2016-03-08 15:08 GMT+01:00 Thomas Andraschko <andraschko.thomas at gmail.com>:

> +1
>
> I also use a own implementation of @ThreadScoped, but currently only via
> manual start/stop via: ThreadContext.start() or ThreadContext.stop();
>
> If provide something, how will it act in a servlet environment? Will it
> share the same length as RequestScoped?
> Threads are reused by Tomcat AFAIR, so actually it would be longer as one
> request.
>
>
Fair point so we have 2 scopes actually:

- ThreadScoped
- TaskScoped (guess most of people will understand the first one as this
one so we need another name)

Originally I was only thinking to the second one (ie one available during a
task which can be started/stopped implicitely - see my first question - or
manually by the user).

ThreadScoped is however really harder to get right I think cause of the
numerous pools EE has so it can probably be a EE defined scope but at CDI
level I think tackling TaskScoped is easier to start.

wdyt?


> 2016-03-08 14:53 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>
>> In Resin we added it precisely for these reasons and because it is very
>> useful for framework development as opposed to the Java SE thread local
>> API. We started it whenever a thread starts and destroyed it when the
>> thread ends just like thread local. It keeps things simple and consistent.
>>
>> On Mar 8, 2016, at 8:43 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>
>> 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 <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> _______________________________________________
>> 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/20160308/9823fdbc/attachment.html 


More information about the cdi-dev mailing list