4 Replies Latest reply on Oct 15, 2003 4:59 PM by Adrian Brock

    Deadlock not detected?

    natemc Newbie

      We're trying to port our EJB app from Weblogic to JBoss 3.2.1 (on RedHat Linux 7.2).

      For some operations, the client and server will both hang until the timeout (in transaction-service.xml) is reached. Setting the timeout to a small value (e.g., 3 seconds) makes the app appear relatively normal.

      I expected the deadlock to be detected and one of the waiting transactions to be notified right away with an ApplicationDeadlockException.

      I've attached a stack trace.

      Thanks in advance,
      Nate

        • 1. Re: Deadlock not detected?
          Adrian Brock Master

          There is one deadlock we don't detect.
          The RequiresNew self deadlock.

          We cannot detect deadlocks we don't know about,
          e.g. contraints in the database (without supporting indexes)
          can hold locks other than the row lock.

          What database isolation do you have?

          Regards,
          Adrian

          • 2. Re: Deadlock not detected?
            natemc Newbie

            > There is one deadlock we don't detect.
            > The RequiresNew self deadlock.

            That was it. Thanks!
            Nate

            • 3. Re: Deadlock not detected?
              the_bone_ranger Newbie

              I've had this problem too, I changed my code, so I never use RequiresNew.

              It would never timeout for me either, is this a fault of my db driver or JBoss? Do I have to set up my database to timeout?

              Will this deadlock occur only under certain conditions?, or can you expect it to happen anytime RequiresNew is used ?
              (i.e. can you write your code using RequiresNew in such a way that you are guaranteed to never see this deadlock)




              • 4. Re: Deadlock not detected?
                Adrian Brock Master

                Ensure you never invoke a method with RequiresNew when the
                entity instance is already locked to the current transaction.

                bean.doSomething(); // Locks bean to current transaction
                bean.doSomethingWithRequiresNew(); // Cannot lock the bean

                Of course the code is never that simple to spot. :-)

                Regards,
                Adrian