| 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
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._______________________________________________
--
Thanks
Emily
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
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev