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