6 Replies Latest reply on Nov 21, 2002 5:30 PM by adrian.brock

    Transaction Deadlocks with CMR

    _scottwilliams_
    _scottwilliams_ Nov 19, 2002 10:28 PM

      We are having bad deadlocking problems with JBoss 3.03 CMR. For the most part our entity beans are read only. It looks like if one thread get's an instance of a parent object and uses cmr to iterate through its children and if at the same time another thread gets an instance of one of the children and tries to get the parent we get a deadlock problem. I could understand why this would happen if we were doing updates, but we are just reading data. In the database world this is solved by using shared locks for reads. Is there something equivilent to this in jboss. What are the locking options in JBoss? How do you change them? DO you just drop a line in the jboss.xml with the
      <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>

      tag set?

      BTW - we have solved our deadlock problems by reducing our use of CMR, but one of the main reasons we decided to use CMP was CMR.



      • 2201 Views
      • Tags:
        • 1. Re: Transaction Deadlocks with CMR
          adrian.brock Nov 20, 2002 12:44 PM (in response to _scottwilliams_)

          in jboss.xml

          <ejb-name>whatever</ejb-name>
          <method-attributes>

          <method-name>get*</method-name>
          <read-only>true</read-only>

          </method-attributes>
          </ejb-name>

          Regards,
          Adrian

            • Actions
          • 2. Re: Transaction Deadlocks with CMR
            minamoto
            minamoto Nov 20, 2002 9:37 PM (in response to _scottwilliams_)

            I'm afraid that the method-attributes element is in jboss_3_1.dtd.

            Miki

              • Actions
            • 3. Re: Transaction Deadlocks with CMR
              adrian.brock Nov 20, 2002 10:16 PM (in response to _scottwilliams_)

              That must be a mistake.
              The code for read-only methods was added before
              the 3.0.0RC1 release

              Regards,
              Adrian

                • Actions
              • 4. Re: Transaction Deadlocks with CMR
                minamoto
                minamoto Nov 20, 2002 11:32 PM (in response to _scottwilliams_)

                > That must be a mistake.

                Could you tell me how we can use the usuful feature with JBoss 3.0.x?
                I wonder we could drop the dtd declaration from jboss.xml or use jboss_3_1.dtd instead.

                Miki


                  • Actions
                • 5. Re: Transaction Deadlocks with CMR - the answer!
                  _scottwilliams_
                  _scottwilliams_ Nov 21, 2002 1:46 PM (in response to _scottwilliams_)

                  I found the answers to my questions about deadlocking in the JBoss Administration and Development Book. Chapter 5 of this book covers the topic in detail. If anyone else is having problems with deadlocks, I highly recomend getting that book and reading chapt. 5.

                  Basically I created a configuration that uses commit option a and <read only> tag for my read only beans and used the instance per transaction method for my write beans (which seems a lot like optimistic locking). Anyway, the deadlocks are gone and performance looks excellent so far.

                  One thing I have yet to explore is the option to make methods readonly. Not sure exactly how this works by my understanding is that if you have a mostly read -only bean you can go with commit option a, pesimistic locking and make all the getters read-only, which will prevent the object from locking until you do a write.

                  One thing I don't understand is why the default options of jboss are set with the pessimistic locking on reads. It seems like any application that has any sort of volume would experience tons of deadlocks with the default config.

                    • Actions
                  • 6. Re: Transaction Deadlocks with CMR - the answer!
                    adrian.brock Nov 21, 2002 5:30 PM (in response to _scottwilliams_)

                    Deadlocks are an ordering problem. Sometimes
                    they can't be avoided.
                    3.0.5 will include automatic retries of deadlocked
                    transactions (up-to 5 times).

                    read-only methods work like a RequiresNew transaction
                    except within the same transaction.
                    The lock is released on return from the method,
                    without waiting for whole transaction to commit.

                    Imagine Thread 1 does
                    config.getValue()

                    Thread 2 then does
                    config.setValue()

                    Thread 1 now uses "value", it is out-of-date without
                    pessimistic locking.
                    Hence pessimistic is the default.
                    The principal of no suprises.

                    Regards,
                    Adrian

                      • Actions