Re: ThreadContext handling, context propagation, multi-threaded issues

Looking at it now. Given that Geronimo Transaction Manager ties the
transaction to the thread, we can't support propagating the transaction to
other threads. I wonder if we should remove TxThreadContextProvider
altogether?

Jon

On Sat, Sep 13, 2025 at 7:51 PM Richard Zowalla <[email protected]> wrote:

> Hi all,
>
> I guess that https://github.com/apache/tomee/pull/2033 still waits for a
> review.
> As far as I can tell, it removes the transaction propagation.
>
> Gruß
> Richard
>
> > Am 31.07.2025 um 08:23 schrieb Markus Jung <[email protected]>:
> >
> > Hey David,
> >
> >
> > sorry for replying a bit late, but I haven't touched concurrency in
> basically a year and our use-case for it is pretty basic I have to admit.
> So I also need to skim through the spec to understand why I built things
> this way.
> >
> > First of all I commented on the PR that caused all of this (
> https://github.com/apache/tomee/pull/1996#issuecomment-3130863438).
> Reading through your messages what I did actually makes a lot of sense;
> begin a _new_ ThreadContext and when the Concurrency Context ends exit it
> and restore the old ThreadContext if there was one. So IMO this looks good.
> >
> >
> > I think the interesting part right now is in the ContextService part of
> the Concurrency Spec, as everything else like Managed Threads, Managed
> (Scheduled) Executor service, etc. depends on it and is IIRC just some
> sugar coating on top of the ContextService to not invoke it manually in
> tasks. Here the spec knows of 3 different types of Contexts that can be
> cleared/ignored/propagated: Application, Security and Transaction.
> Application/Security was basically there before I started working on
> concurrency (except for the ThreadContext enter/exit in
> ApplicationThreadContextProvider)  but TxThreadContextProvider was empty,
> so I naturally started implementing it to pass the TCK.
> >
> > Interestingly enough reading through relevant spec/javadocs again I
> found:
> > - in §2.3: "The types of contexts to be propagated from a
> contextualizing application component include JNDI n aming context,
> classloader, and security information. Containers must support propagation
> of these context types. In addition, containers can choose to support
> propagation of other types of context." -> sounds like Transaction
> propagation not being a requirement
> > - in §3.3.5 "By default, proxy methods suspend any transactional context
> on the thread and allow components to manually control global transaction
> demarcation boundaries. Context objects may optionally begin, commit, and
> rollback a transaction. See EE.4 for details on transaction management in
> Jakarta EE. By using an execution property when creating the contextual
> proxy object, application components can choose to not suspend the
> transactional context on the thread, and any resources used by the task
> will be enlisted to that transaction."
> > - @ContextServiceDefinition javadoc: "Jakarta EE providers need not
> support the propagation of transactions to other threads and can reject
> resource definition annotations that include transaction as a propagated
> context."
> > - There is also https://github.com/jakartaee/concurrency/issues/102
> >
> >
> > This all sounds to me like implementing
> TxThreadContextProvider#currentContext was straight up wrong and we must
> delete it alongside the propagateTx flag Jon introduced and reject
> ContextService resources that have propagated*=TRANSACTION, that should
> clear things up a lot I think.
> >
> >
> > @Jon, maybe you also have some thoughts on this?
> >
> >
> > Thanks
> >
> > Markus
> >
> >
> > On 31.07.25 00:47, David Blevins wrote:
> >>> On Jul 30, 2025, at 3:45 PM, David Blevins <[email protected]>
> wrote:
> >>>
> >>> A good chunk of these requirements appear to come from the Jakarta
> Concurrency spec.  I've not read that one yet and don't have the bandwidth
> to become an expert in it and the TCK requirements.
> >>>
> >>> Markus & Jon, any chance you'd want to give an overview of what
> features the TCK is specifically requesting we implement?
> >> And specifically what stuff needs to be propagated to the threads it
> spawns.  That's really the key part.
> >>
> >>
> >> -David
> >>
> >>
> >>
>
>