You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "Markus Jung (Jira)" <ji...@apache.org> on 2025/08/02 19:37:00 UTC

[jira] [Created] (TOMEE-4518) Remove transaction propagation

Markus Jung created TOMEE-4518:
----------------------------------

             Summary: Remove transaction propagation
                 Key: TOMEE-4518
                 URL: https://issues.apache.org/jira/browse/TOMEE-4518
             Project: TomEE
          Issue Type: Improvement
            Reporter: Markus Jung
            Assignee: Markus Jung
             Fix For: 10.1.1


See [https://lists.apache.org/thread/9hhxsrclzhc49ln74xc029j836d6g7zq]

Quoting David's initial mail:
{noformat}
The Geronimo TransactionManager is not capable of supporting a transaction across multiple threads. To my knowledge it uses a ThreadLocal itself to track state and related code such as UserTransaction, TransactionSynchronizationRegistry and JTA as a spec are not capable for coordinating one transaction across multiple threads, nor are specs on top such as JPA.{noformat}

After a quick look it indeed looks like Geronimo txmanager internally uses ThreadLocals (e.g. https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java) to store Transaction state, so we should not try to be smart and propagate it.

Reading through the concurrency spec I also found no hard requirement to support tx propagation, instead:
* 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."



--
This message was sent by Atlassian Jira
(v8.20.10#820010)