Thank you for sharing your experiment! What you described is pretty much what MicroProfile Context Propagation does (capature, attach). See here for more information. Nathan is trying to get these functionalities in Jakarta Concurrency so that other Jakarta specs such as CDI can use it to propagate some contexts including custom context. Please join today's call to discuss this further.
The idea is that before entering a concurrent execution, the
backing storage of the contexts is captured, and possibly replaced
with a thread safe variant. Tasks that are run on a certain thread
pool then attach/detach these contexts. It would be great if the
CDI API could offer an SPI to do this capturing + attach/detach
and allow custom contexts to opt into this, to allow context
sharing through managed thread pools.
My main use case is to trigger the run of multiple producers in
parallel in a pre-step to speed up certain follow up processes. In
a PoC I was able to scan a JSF page for simple named
EL-Expressions e.g. `#{beanFromProducer}`, look at the producer
method to check if parallel pre-loading is allowed and then submit
tasks to a managed thread pool, that simply create an instance of
the bean. I had to wait for all tasks to finish before proceeding
to avoid duplicate beans due to main thread producer calls, but I
guess I could have avoided this by using an interceptor that
returns a lazy proxy. Overall this improved page loading times by
a lot, but that is just one of the use cases I had in mind.
Parallel database access currently always has to be implemented
in a special way because these services can't make use of CDI
beans without something like MP Context Propagation. I would like
to be able to code something like this:
private void loadData() {
Future<String> f1 = someMethod1();
Future<String> f2 = someMethod2();
f1.get(); f2.get();
// Do something with the data
}
Without having to worry about explicit
context propagation.
Regards,
Christian
Am 12.10.2021 um 08:57 schrieb Ladislav
Thon:
Hi,
I'd like to suggest that someone should come up with a
concrete proposal, otherwise we'll have a vague discussion
that leads nowhere.
There's a considerable amount of experience with
MicroProfile Context Propagation and based on that experience,
I'm pretty confident in saying that context propagation makes
it very easy to shoot oneself in the foot [with a decently
sized bazooka]. To the best of my knowledge, MicroProfile
Context Propagation was designed with an assumption that
there's still a single logical thread of execution,
even if that execution sometimes switches physical
threads, and that the context lifecycle doesn't change. Alas,
that is impossible to enforce, so many people end up in a
situation when they share contexts between multiple
concurrently executing threads. Which is fine for the
application context, obviously, but it's almost always a bad
idea for the request context, because request scoped beans are
almost never thread safe. (Ignoring session and conversation
context here, but I think they are close to the request
context in this particular case.)
So, yea, this is an important problem. Does anyone have a
concrete proposal to discuss? 'Without that, I fear it's a
waste of time. (I said it before and I'll say it again. I'm a
simple man. I prefer concrete proposals over abstract
discussions.)
LT
On Mon, Oct 11, 2021 at 11:47
PM Emily Jiang via cdi-dev <cdi-dev@xxxxxxxxxxx>
wrote:
In tomorrow's call, I would like to discuss the
CDI context propagation issue as
Jakarta Concurrency and Batch would like to interact with
this capability. Please attend if you are interested in this
area.