[
https://issues.apache.org/jira/browse/TOMEE-4518?focusedWorklogId=983554&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-983554
]
ASF GitHub Bot logged work on TOMEE-4518:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 17/Sep/25 20:47
Start Date: 17/Sep/25 20:47
Worklog Time Spent: 10m
Work Description: jgallimore commented on PR #2033:
URL: https://github.com/apache/tomee/pull/2033#issuecomment-3304518170
This looks good to me. I've rebased it. +1 to merge.
Issue Time Tracking
-------------------
Worklog Id: (was: 983554)
Time Spent: 0.5h (was: 20m)
> 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
> Priority: Major
> Fix For: 10.1.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See [https://lists.apache.org/thread/9hhxsrclzhc49ln74xc029j836d6g7zq]
> Quoting David's initial mail:
> 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.
> 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)
