[jira] [Work logged] (TOMEE-4518) Remove transaction propagation

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TOMEE-4518?focusedWorklogId=977425&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-977425 ]

ASF GitHub Bot logged work on TOMEE-4518:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 02/Aug/25 20:07
            Start Date: 02/Aug/25 20:07
    Worklog Time Spent: 10m 
      Work Description: jungm opened a new pull request, #2033:
URL: https://github.com/apache/tomee/pull/2033

   See [TOMEE-4518](https://issues.apache.org/jira/browse/TOMEE-4518) and [this thread](https://lists.apache.org/list.html?dev@tomee.apache.org) on the dev list
   
   Maybe we should think out loud about failing the deployment of a `ContextService` if it defines `Propagated*=Transaction`. This however brings up questions again like what to do in this case:
   ```
   <Resource id="Foo" type="ContextService">
     Propagated = Remaining
     Cleared =
     Unchanged =
   </Resource>
   ```
   And if we should completely abort the TomEE startup if an illegal ContextService is detected in `tomee.xml`. What if it has `Lazy=true`? So I chose to not enforce this via code yet.




Issue Time Tracking
-------------------

            Worklog Id:     (was: 977425)
    Remaining Estimate: 0h
            Time Spent: 10m

> 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.1
>
>          Time Spent: 10m
>  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)