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 <ju...@apache.org>: > > 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 >> >> >>
