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