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

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