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 <david.blev...@gmail.com> 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
