Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-7282

Deadlock in BasicAction when jboss remoting and JTA is used

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 11.0.0.Alpha1
    • 10.1.0.Final
    • EJB
    • None
    • Hide

      You need a reinvocation at a server that was already participating in the transaction, as the scenario below for example:
      server1 -> server2 -> server1

      Show
      You need a reinvocation at a server that was already participating in the transaction, as the scenario below for example: server1 -> server2 -> server1

      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/2016-September/msg00000.html

      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.

              flaviarnn Flavia Rainone
              flaviarnn Flavia Rainone
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: