Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] tomorrow's cdi call
Just wanted to follow up on this. The proposal is basically to adopt MicroProfile Context Propagation. I think that's overall the most reasonable thing to propose, though I have no idea what to do with the problems with mutable contexts (lifecycle, concurrent access, backwards propagation, maybe there's more?). As Nathan said yesterday on the call, a lot of these are arguably usage errors, but these usage errors are easy to make, hard to detect and impossible to prevent.

Also, as far as I know, there's just 2 ways how to actually use context propagation: manually creating a "contextual" runnable/callable/whatever, or submitting a task to a "contextual" executor. There's no direct control over which contexts are propagated, which makes the API easier to use on surface, but also more prone to the usage errors per above. Again, I have no idea whether anything could/should be done with this. The more I learned about MicroProfile Context Propagation, to more I knew it's a powerful and dangerous thing :-)

LT

On Tue, Oct 12, 2021 at 11:53 AM Emily Jiang via cdi-dev <cdi-dev@xxxxxxxxxxx> wrote:
Thanks Christian! What you described is the mutability aspect. It will be very difficult to handle as there could be multiple threads with the changes. I don't think it can be done easily. We will try to record the conversation in minutes so that you can catch up with it.

Thanks
Emily

On Tue, Oct 12, 2021 at 10:49 AM Christian Beikov <christian.beikov@xxxxxxxxx> wrote:

Hi Emily,

unfortunately I can't join you today as I am on a train all day long with bad internet connection quality.

Looks like MP Context Propagation handles most of my requirements now. It would be great if the possibility existed to allow beans that were created in a different thread, to be added/merged back to the originating context. This would help my parallel producer use case. Not sure if that is already possible with MP Context Propagation. Either way, it's nice to see this finally being handled in the Jakarta specs :)

Am 12.10.2021 um 11:28 schrieb Emily Jiang via cdi-dev:
Hi Christian,

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.

Thanks
Emily

On Tue, Oct 12, 2021 at 10:16 AM Christian Beikov <christian.beikov@xxxxxxxxx> wrote:

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


--
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


--
Thanks
Emily

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev

Back to the top