@ThreadScoped?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

@ThreadScoped?

Romain Manni-Bucau
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Reza Rahman
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Thomas Andraschko
+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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Romain Manni-Bucau

2016-03-08 15:08 GMT+01:00 Thomas Andraschko <[hidden email]>:
+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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Reza Rahman
In reply to this post by Thomas Andraschko
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Mark Struberg
In reply to this post by Romain Manni-Bucau
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 <[hidden email]>:
>
> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Romain Manni-Bucau
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 <[hidden email]>:
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 <[hidden email]>:
>
> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Reza Rahman
In reply to this post by Mark Struberg
To save time I suggest looping in someone knowledgable and level headed from the Servlet EG if they are not here already. I can certainly vouch for either Ed, Shingwai or Greg.

> On Mar 10, 2016, at 1:43 PM, Mark Struberg <[hidden email]> d wrote:
> Save
> 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 <[hidden email]>:
>>
>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Mark Struberg
In reply to this post by Romain Manni-Bucau
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 <[hidden email]>:
>
> 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 <[hidden email]>:
> 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 <[hidden email]>:
> >
> > 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
> > [hidden email]
> > 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Reza Rahman
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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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 <[hidden email]>:
>> 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 <[hidden email]>:
>>>
>>> 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
>>> [hidden email]
>>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Mark Struberg
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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Stephan Knitelius
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.

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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

arjan tijms
Hi,

On Saturday, March 19, 2016, Stephan Knitelius <[hidden email]> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;struberg@yahoo.de&#39;);" target="_blank">struberg@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;reza_rahman@lycos.com&#39;);" target="_blank">reza_rahman@...>:
>
> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;struberg@yahoo.de&#39;);" target="_blank">struberg@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;rmannibucau@gmail.com&#39;);" target="_blank">rmannibucau@...>:
>>>
>>> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;struberg@yahoo.de&#39;);" target="_blank">struberg@...>:
>>> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;rmannibucau@gmail.com&#39;);" target="_blank">rmannibucau@...>:
>>>>
>>>> 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
>>>> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdi-dev@lists.jboss.org&#39;);" target="_blank">cdi-dev@...
>>>> 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
>> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdi-dev@lists.jboss.org&#39;);" target="_blank">cdi-dev@...
>> 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
> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdi-dev@lists.jboss.org&#39;);" target="_blank">cdi-dev@...
> 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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdi-dev@lists.jboss.org&#39;);" target="_blank">cdi-dev@...
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Stephan Knitelius
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 <[hidden email]> wrote:
Hi,

On Saturday, March 19, 2016, Stephan Knitelius <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

arjan tijms
Hi,

On Sat, Mar 19, 2016 at 10:02 PM, Stephan Knitelius <[hidden email]> 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 <[hidden email]> wrote:
Hi,

On Saturday, March 19, 2016, Stephan Knitelius <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Manfred Riem
In reply to this post by Stephan Knitelius
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Reza Rahman
As discussed elsewhere in this EG, even in the most pessimistic reading of the current spec, all that would be needed is a flag on the existing annotation. It's not out of the question at all.

On Mar 20, 2016, at 1:36 PM, Manfred Riem <[hidden email]> wrote:

Why is changing @RequestScoped out of the question? 

From my perspective when an AsyncContext is started the request is still there. 

It is just being served by a different thread.

Certainly there is a need to work with the Servlet EG to figure out how to transfer “ownership” to the AsyncContext.

Anyway my 2 cents

Thanks!

Kind regards,
Manfred Riem

On Mar 19, 2016, at 3:35 PM, Stephan Knitelius <[hidden email]> 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.

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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Mark Struberg
A scope annotation cannot have a flag.

LieGrue,
strub




On Sunday, 20 March 2016, 20:25, Reza Rahman <[hidden email]> wrote:


>
>
>As discussed elsewhere in this EG, even in the most pessimistic reading of the current spec, all that would be needed is a flag on the existing annotation. It's not out of the question at all.
>
>On Mar 20, 2016, at 1:36 PM, Manfred Riem <[hidden email]> wrote:
>
>
>Why is changing @RequestScoped out of the question?
>>
>>
>>From my perspective when an AsyncContext is started the request is still there.
>>
>>
>>It is just being served by a different thread.
>>
>>
>>Certainly there is a need to work with the Servlet EG to figure out how to transfer “ownership” to the AsyncContext.
>>
>>
>>Anyway my 2 cents
>>
>>
>>Thanks!
>>
>>
>>Kind regards,
>>Manfred Riem
>>
>>
>>On Mar 19, 2016, at 3:35 PM, Stephan Knitelius <[hidden email]> 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.
>>>
>>>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 <[hidden email]> 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 <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>
>>>>>>> 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 <[hidden email]>:
>>>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>>[hidden email]
>>>>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
>>>[hidden email]
>>>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
>[hidden email]
>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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Romain Manni-Bucau


Le 20 mars 2016 20:40, "Mark Struberg" <[hidden email]> a écrit :
>
> A scope annotation cannot have a flag.
>

Why? Technically it can

> LieGrue,
> strub
>
>
>
>
> On Sunday, 20 March 2016, 20:25, Reza Rahman <[hidden email]> wrote:
>
>
> >
> >
> >As discussed elsewhere in this EG, even in the most pessimistic reading of the current spec, all that would be needed is a flag on the existing annotation. It's not out of the question at all.
> >
> >On Mar 20, 2016, at 1:36 PM, Manfred Riem <[hidden email]> wrote:
> >
> >
> >Why is changing @RequestScoped out of the question?
> >>
> >>
> >>From my perspective when an AsyncContext is started the request is still there.
> >>
> >>
> >>It is just being served by a different thread.
> >>
> >>
> >>Certainly there is a need to work with the Servlet EG to figure out how to transfer “ownership” to the AsyncContext.
> >>
> >>
> >>Anyway my 2 cents
> >>
> >>
> >>Thanks!
> >>
> >>
> >>Kind regards,
> >>Manfred Riem
> >>
> >>
> >>On Mar 19, 2016, at 3:35 PM, Stephan Knitelius <[hidden email]> 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.
> >>>
> >>>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 <[hidden email]> 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 <[hidden email]>:
> >>>>>
> >>>>> 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 <[hidden email]> 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 <[hidden email]>:
> >>>>>>>
> >>>>>>> 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 <[hidden email]>:
> >>>>>>> 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 <[hidden email]>:
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>> [hidden email]
> >>>>>>>> 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
> >>>>>> [hidden email]
> >>>>>> 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
> >>>>> [hidden email]
> >>>>> 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
> >>>>[hidden email]
> >>>>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
> >>>[hidden email]
> >>>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
> >[hidden email]
> >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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: @ThreadScoped?

Mark Struberg
In reply to this post by Romain Manni-Bucau
See Bean#getScope() and BeanManager#getContext()

Just uses Class and no Annotation instance.

Lgm


--------------------------------------------
On Sun, 20/3/16, Romain Manni-Bucau <[hidden email]> wrote:

 Subject: Re: [cdi-dev] @ThreadScoped?
 To: "Mark Struberg" <[hidden email]>
 Cc: [hidden email], "Reza Rahman" <[hidden email]>
 Date: Sunday, 20 March, 2016, 20:47
 
 Le 20 mars 2016 20:40,
 "Mark Struberg" <[hidden email]>
 a écrit :
 >
 > A scope
 annotation cannot have a flag.
 >
 
 Why? Technically it can
 
 > LieGrue,
 > strub
 >
 >
 >
 >
 >
 On Sunday, 20 March 2016, 20:25, Reza Rahman <[hidden email]>
 wrote:
 >
 >
 > >
 > >
 > >As discussed
 elsewhere in this EG, even in the most pessimistic
 reading
 of the current spec, all that would
 be needed is a flag on the existing
 annotation. It's not out of the question at
 all.
 > >
 > >On
 Mar 20, 2016, at 1:36 PM, Manfred Riem <[hidden email]>
 wrote:
 > >
 >
 >
 > >Why is changing @RequestScoped
 out of the question?
 > >>
 > >>
 > >>From
 my perspective when an AsyncContext is started the request
 is
 still there.
 >
 >>
 > >>
 >
 >>It is just being served by a different thread.
 > >>
 > >>
 > >>Certainly there is a need to work
 with the Servlet EG to figure out how
 to
 transfer “ownership” to the AsyncContext.
 > >>
 > >>
 > >>Anyway my 2 cents
 > >>
 > >>
 > >>Thanks!
 >
 >>
 > >>
 >
 >>Kind regards,
 > >>Manfred
 Riem
 > >>
 >
 >>
 > >>On Mar 19, 2016, at
 3:35 PM, Stephan Knitelius <[hidden email]>
 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.
 >
 >>>
 > >>>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 <[hidden email]>
 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 <[hidden email]>:
 > >>>>>
 >
 >>>>> 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 <[hidden email]>
 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 <
 [hidden email]>:
 > >>>>>>>
 > >>>>>>> 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 <[hidden email]>:
 > >>>>>>> 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 <
 [hidden email]>:
 > >>>>>>>>
 > >>>>>>>> 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
 >
 >>>>>>>> [hidden email]
 > >>>>>>>> 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
 > >>>>>> [hidden email]
 > >>>>>> 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
 > >>>>> [hidden email]
 > >>>>> 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
 > >>>>[hidden email]
 > >>>>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
 > >>>[hidden email]
 > >>>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
 > >[hidden email]
 > >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
 >
 [hidden email]
 > 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
[hidden email]
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.
12