[cdi-dev] @ThreadScoped?

[Reza Rahman]

FYI thread instances are also re-used in application server environments via managed thread pools. They are considered started when retrieved from the thread pool and run. They are considered to end when returned back to the thread pool. All this happens transparent to the end user. As far as they are concerned they are simply getting new threads. As a result even with pooling in play the thread scope will always be equal to or shorter than an HTTP request.

> On Mar 8, 2016, at 9:08 AM, Thomas Andraschko <andraschko.thomas at gmail.com> wrote:
> 
> +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.
> 
> 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 |  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.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160308/e43ac958/attachment.html