6 Replies Latest reply on Jan 17, 2005 8:17 PM by dragon_jdh

    dead lock

    dragon_jdh

      jboss3.2.3 sql server 2000

      I have a timertask, run in background regularly. it will visit an entity bean, suppose A.

      And also there are other places visit that bean.

      all the methods are 'required' configuration. the isolation level is pessimistic

      now I often met deadlock exception.

      How do I resolve this problem?

        • 1. Re: dead lock
          hariv

          There are different locks on entity bean

          Method Lock

          The method lock ensures that only one thread of execution at a time can invoke on a given Entity Bean. This is required by the EJB spec. But, this single-threadedness, can be overridden by marking the bean reentrant in its deployment descriptor.


          Transaction Lock

          This means that if any method at all is invoked on an Entity Bean within a transaction, no other transaction can have access to this bean until the holding transaction
          commits or is rolled back.

          Please check whether your transactions are long. Check whether your access to the entity bean is ordered.


          If it is still a problem, you can configure your entity bean as instance per transaction which will wipe away deadlock,but you will loose entity bean caching

          • 2. Re: dead lock
            hariv

            I forgot to check one think what is the exact exception message is it an exception from SQL Server or from entity bean. My previous reply was applicable for entity bean lock.

            • 3. Re: dead lock
              dragon_jdh

              thanks,HariV
              two more question:
              1: how to configure your entity bean as instance per transaction ?
              2: I change the lock to JDBCOptimisticLock by modify standardjboss.xml, the deadlock disappear. but new error happend. the exception is:
              2005-01-12 10:44:49,147 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException:
              java.lang.reflect.UndeclaredThrowableException
              at $Proxy189.getId(Unknown Source)
              ......
              Caused by: java.lang.InterruptedException
              at java.lang.Object.wait(Native Method)
              at org.jboss.ejb.plugins.lock.NonReentrantLock.acquire(NonReentrantLock.java:81)
              at org.jboss.ejb.plugins.lock.NonReentrantLock.attempt(NonReentrantLock.java:105)
              at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:82)
              at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:163)
              at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:89)
              at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:54)
              at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
              at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267)
              at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
              at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118)
              at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
              at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
              at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489)
              at org.jboss.ejb.Container.invoke(Container.java:700)
              at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:375)
              at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
              ... 94 more


              thanks again

              • 4. Re: dead lock
                hariv

                This is a sample configuration for instance-per-transaction.


                <ejb-name>DocumentType</ejb-name>
                <jndi-name>ejb/DocumentType</jndi-name>
                <local-jndi-name>DocumentTypeLocal</local-jndi-name>
                <configuration-name>Instance Per Transaction CMP 2.x EntityBean</configuration-name>

                <method-attributes>
                </method-attributes>




                • 5. Re: dead lock
                  dragon_jdh

                  I change the bean to 'instance per transaction...', and add synchronize in some place, the deadlock disappear again. but I got following exception:
                  java.util.ConcurrentModificationException
                  ...

                  I found the configuration for 'instance per transa..' is nolock, and also I change the commit option to A. because in our codes, all update operations are done by entity bean.

                  what shall I do? thanks.

                  • 6. Re: dead lock
                    dragon_jdh

                    I did some modification as following:

                    1: modify jboss.xml, add one container configuration as following:

                    <container-configurations>
                    <container-configuration extends="Instance Per Transaction CMP 2.x EntityBean">
                    <container-name>Optimistic CMP EntityBean</container-name>
                    <locking-policy>org.jboss.ejb.plugins.lock.JDBCOptimisticLock</locking-policy>
                    <commit-option>B</commit-option>
                    </container-configuration>
                    </container-configurations>

                    then shift the special bean to this configuration.

                    2: configure locking policy for the special bean in jbosscmp-jdbc.xml.

                    <load-groups>
                    <load-group>
                    <load-group-name>wo</load-group-name>
                    <field-name>statusDicId</field-name>
                    <field-name>plannedStartDateTime</field-name>
                    </load-group>
                    </load-groups>

                    <optimistic-locking>
                    <group-name>wo</group-name>
                    </optimistic-locking>


                    3: add synchronize in some places which shouldn't be concurrent invoking.

                    then my system passed the test of loadrunner.