reza_rahman at lycos.com
Tue Mar 8 08:53:13 EST 2016
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.
> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app):
> - start/stop API (this is typically an API the user should be able to control for its own threads)
> - CDI 2.*0*?
> Romain Manni-Bucau
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> 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...
More information about the cdi-dev