InvocationScoped | RequestScoped thread context

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

InvocationScoped | RequestScoped thread context

Sebastian Daschner
Hi experts,

Regarding scopes, specificly @RequestScoped: We found in enterprise
projects that there is a need for a request / invocation scope that is
active during an invocation of a business method (HTTP, JMS, EJB, timer,
whatever), regardless how many threads are involved. Naively, one could
presume that @RequestScoped would deal that, but since it's strictly
single threaded and not accessible from asyncronously started threads
(ManagedExecuterService and so forth) that doesn't help much.

This scope would e.g. enable correlation IDs that are needed in all
threads started from one original invocation. Name is up to better
suggestions :-)

I guess it's not possible to change the behavior of @RequestScoped and
to make it available in asyncronously started threads? Have there been
considerations for adding such a scope or similar in the past?

Cheers,
Sebastian

_______________________________________________
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: InvocationScoped | RequestScoped thread context

Romain Manni-Bucau
Hi Sebastian

Think we spoke of it and request scope is single threaded but should propagate following servlet spec. That said i agree cdi misses a manually controlled and inheritable scope. Implemented it 4-5 times last 2 years.


Le 7 janv. 2017 13:45, "Sebastian Daschner" <[hidden email]> a écrit :
Hi experts,

Regarding scopes, specificly @RequestScoped: We found in enterprise
projects that there is a need for a request / invocation scope that is
active during an invocation of a business method (HTTP, JMS, EJB, timer,
whatever), regardless how many threads are involved. Naively, one could
presume that @RequestScoped would deal that, but since it's strictly
single threaded and not accessible from asyncronously started threads
(ManagedExecuterService and so forth) that doesn't help much.

This scope would e.g. enable correlation IDs that are needed in all
threads started from one original invocation. Name is up to better
suggestions :-)

I guess it's not possible to change the behavior of @RequestScoped and
to make it available in asyncronously started threads? Have there been
considerations for adding such a scope or similar in the past?

Cheers,
Sebastian

_______________________________________________
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: InvocationScoped | RequestScoped thread context

Matej Novotny
Hi

Manual context activation had been implemented in CDI 2.0 for RequestScope[1] as a part of CDI-30[2].
I know that's probably not what you are after, just saying that it's headed that way.
As for context propagation, there is an issue too (CDI-618[3] I think).
I recall there was quite a discussion about it and possibly even more issues raised (like CDI-587) but no real
action taken as this turns out to be very complex case to cover with "general" implementation.

BTW due to backward compatibility, RequestScoped cannot be changed for sure.

Matej
__________________________________________________________________________-
[1] http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#activating_request_context
[2] https://issues.jboss.org/browse/CDI-30
[3]https://issues.jboss.org/browse/CDI-618



----- Original Message -----

> From: "Romain Manni-Bucau" <[hidden email]>
> To: "Sebastian Daschner" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> Sent: Saturday, January 7, 2017 4:13:41 PM
> Subject: Re: [cdi-dev] InvocationScoped | RequestScoped thread context
>
> Hi Sebastian
>
> Think we spoke of it and request scope is single threaded but should
> propagate following servlet spec. That said i agree cdi misses a manually
> controlled and inheritable scope. Implemented it 4-5 times last 2 years.
>
>
> Le 7 janv. 2017 13:45, "Sebastian Daschner" < [hidden email] > a
> écrit :
>
>
> Hi experts,
>
> Regarding scopes, specificly @RequestScoped: We found in enterprise
> projects that there is a need for a request / invocation scope that is
> active during an invocation of a business method (HTTP, JMS, EJB, timer,
> whatever), regardless how many threads are involved. Naively, one could
> presume that @RequestScoped would deal that, but since it's strictly
> single threaded and not accessible from asyncronously started threads
> (ManagedExecuterService and so forth) that doesn't help much.
>
> This scope would e.g. enable correlation IDs that are needed in all
> threads started from one original invocation. Name is up to better
> suggestions :-)
>
> I guess it's not possible to change the behavior of @RequestScoped and
> to make it available in asyncronously started threads? Have there been
> considerations for adding such a scope or similar in the past?
>
> Cheers,
> Sebastian
>
> _______________________________________________
> 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.