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)