2 Replies Latest reply on Nov 20, 2002 6:53 AM by timfox

    commit options, object locking and deadlock

    timfox

      I think I posted this (or at least a similar post) in the wrong forum, so here it is again:

      I am using jboss 3.0.2 and bmp (actually I am using mvcsoft, but in jboss's eyes that's just bmp).

      I'm getting a lot of deadlock detected (and one of the tx rolled back) by the container.

      This happens even though separate concurrent calls very rarely, if ever update the same data.

      I have been informed that jboss exclusively and pessimistically locks ANY entity beans that are involved in the transaction, whether or not they are updated.

      What I am not sure about, is whether this just applies to commit option A, or does the above apply to commit options B and C also?

      Also, in commit option C does each transaction load it's own copy of the particular entity object, or is one instance of the eg. "Joe Bloggs" Person entity bean shared throughout the container, even in commit option C.

      Thirdly, I have noticed the class MethodOnlyEJBLock which appears to avoid the locking problems but I am worried that this would cause inconsistencies in the object states especially if JBoss only has one instance of the object, even in commit option C.

      Any help in answering these questions would be greatly appreciated. As my project is currently dying with the amount of deadlocks it's currently having.

        • 1. Re: commit options, object locking and deadlock
          _scottwilliams_

          Is there any documentation of the different types of locking available in jboss 3.x with information about the pros/cons of each type of locking?

          Also, can I change the locking behavior just by add in a locking tag in the jboss.xml file of my ejb jar?
          <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>

          • 2. Re: commit options, object locking and deadlock
            timfox

            hi scott-

            this is an old message of mine.

            to let you know we solved our problem in the end by using one of the "instance per transaction" container configurations, with commit option C - (and we actually use the excellent MVCSoft for CMP persistence - for performance reasons).

            this config. scales well as opposed to the default config. which (IMO) doesn't scale AT ALL for most normal (ie multi user applications).

            luckily jboss is highly configurable and comes with several pre-defined container configurations for different situations - some are more applicable for enterprise systems, others for clustered systems and others for single user or read-mostly applications.

            you need to be careful which one you choose since the default config. only keeps one instance of each entity and pessimistically locks on it whether on or not it is changed in the transaction - hence is prone to deadlock.

            you can of course roll your own, and choose your own combination of locks and interceptors but if you careful you may end up with a config that either defies the ejb spec, loses ACIDity or has other problems.

            all of this is documented in the paid jboss docs.

            HTH