[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdi-dev] tomorrow's cdi call
|
Hi,
usually I am an observer of this list but I wanted to chime in
here as I tried implementing something like that as PoC before.
Here is a PR that tried to add this through some reflection hacks
to the DeltaSpike ContextControl API:
https://github.com/beikov/deltaspike/commit/3a15d6c3b804166a51346981aad12c36cd779b7d
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:
@Async(mutableContext = true)
private Future<String> someMethod1()
{..}
@Async(mutableContext = false)
private Future<String> someMethod2()
{..}
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
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.
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev