[ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.... ] Flavia Rainone updated WFLY-7282: --------------------------------- Description: At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock. Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/20... Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem. If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back. IIOP/JTS does not suffer with this flaw. was: At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem. Summary: Deadlock in BasicAction when jboss remoting and JTA is used (was: Double diamond in EJB Transaction) -- This message was sent by Atlassian JIRA (v6.4.11#64026)