3 Replies Latest reply on Aug 5, 2002 1:31 PM by Adrian Brock

    ApplicationDeadlockException

    martin Newbie

      hi to all,

      i am experiencing very strange behaviour in jboss 3.0.0. the scenario is as
      follows:

      - a stateless session bean is used as a facade to entity beans (mainly to
      allow
      for the use of local interfaces between session and entity beans).
      - two (or more) simultaneous requests are performed on a method in the
      session bean which results in the instantiation of two session beans.
      two transactions are created as well.
      - the session is extended from an abstract base class which implements
      code used accross multiple session beans (probably this is another
      problem -
      however i tried to put the code of the method in the session bean as well
      which did not improve the situation at all).
      - one of the two requests dies with an ApplicationDeadlockException which
      causes the transaction to be rolled back.

      i didn't find any information on that sort of problem on the net and the
      source-code
      of the BeanLockSupport which throws the exception is not very helpful as
      well.

      the javadoc of ApplicationDeadlockException says:
      * This exception class is thrown when application deadlock is detected when
      trying to lock an entity bean
      * This is probably NOT a result of a jboss bug, but rather that the
      application is access the same entity
      * beans within 2 different transaction in a different order. Remember,
      with a PessimisticEJBLock,
      * Entity beans are locked until the transaction commits or is rolled back.

      after some trial by terror i made the method synchronized which resolved the
      problem.
      however i want to allow for simultaneous requests and therefore making the
      method
      synchronized is one of the last things i want to do.

      many thanks,
      martin.


      ---
      15:03:55,430 ERROR [LogInterceptor] TransactionRolledbackException, causedBy:
      org.jboss.ejb.plugins.lock.ApplicationDeadlockException: application deadlock detected
      at org.jboss.ejb.plugins.lock.BeanLockSupport.deadlockDetection(BeanLockSupport.java:193)
      at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.waitForTx(QueuedPessimisticEJBLock.java:281)
      at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.doSchedule(QueuedPessimisticEJBLock.java:188)
      at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.schedule(QueuedPessimisticEJBLock.java:149)
      at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:103)
      at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69)
      at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
      at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
      at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
      at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
      at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
      at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493)
      at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:296)
      at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
      at $Proxy55.getMembers(Unknown Source)
      at com.xxx.xxx.session.AbstractControllerBean.getGroups(AbstractControllerBean.java:156)
      at com.xxx.xxx.session.LocationControllerBean.getGroups(LocationControllerBean.java:253)
      at java.lang.reflect.Method.invoke(Native Method)
      at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:664)
      at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
      at org.jboss.ejb.plugins.StatelessSessioInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
      at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
      at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
      at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
      at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
      at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
      at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
      at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:296)
      at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:81)
      at $Proxy54.getGroups(Unknown Source)
      at com.xxx.xxx.servlet.FinderCommand.process(FinderCommand.java:59)
      at com.xxx.xxx.servlet.RequestBroker.process(RequestBroker.java:123)
      at com.xxx.xxx.servlet.RequestBroker.doPost(RequestBroker.java:89)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
      at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:371)
      at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:607)
      at org.mortbay.http.HttpContext.handle(HttpContext.java:1387)
      at org.mortbay.http.HttpContext.handle(HttpContext.java:1326)
      at org.mortbay.http.HttpServer.service(HttpServer.java:757)
      at org.jboss.jetty.Jetty.service(Jetty.java:527)
      at org.mortbay.http.HttpConnection.service(HttpConnection.java:742)
      at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:915)
      at org.mortbay.http.HttpConnection.handle(HttpConnection.java:757)
      at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:151)
      at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287)
      at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715)
      at java.lang.Thread.run(Thread.java:479)

        • 1. Re: ApplicationDeadlockException
          Adrian Brock Master

          Making the method synchronized is also against the spec.

          There is a section in the quick start guide on deadlocks.
          The problem is the order in which you access the entities.
          http://sourceforge.net/project/showfiles.php?group_id=22866

          Regards,
          Adrian

          • 2. Re: ApplicationDeadlockException
            martin Newbie

            hi adrian,

            thanks for your quick response. however i cannot really
            tell which ejb's are knocking each other out. this is
            how it looks like:

            PosControllerBean implements two methods:

            getPositions: access to the enitities User, Group and GroupMember (the members are CMR and mapped to be target-relationships). Calls to this method take a relatively long time as multiple http requests to retrieve some additionial information are performed.

            getGroups: access to the same entities but very short in terms of processing time.

            The client calls getPositions first, then getGroups. In case this is done simultaneously by two clients getPositions and getGroups are interfering and the exception is thrown. At the moment i got no clue how to refactor that...

            regards, martin.

            • 3. Re: ApplicationDeadlockException
              Adrian Brock Master

              First I am no CMP expert. :-)

              Your problem will be something like:

              Thread1 accesses the User
              Thread2 accesses the Group
              Thread1 waits for the Group
              Thread2 waits for the User
              Deadlock

              If it is not happening very often, just catch
              the exception and retry in a new transaction.

              If this isn't an option, you should probably get
              Dain's book. This should explain how to optimize
              the entity bean access and how to perform read-only
              access without locking the entities until the end
              of the transaction.

              Regards,
              Adrian