2 Replies Latest reply on Nov 7, 2003 12:33 PM by Ivan O. Parra

    Serious deadlock problem

    gorano Newbie

      We have a serious deadlock problem using JMs and MDBs.

      Before we push a message on to the queue we do a precheck if the status in the MTGroup entity is ok. We get the MTgroups from another entity using CMR and many to many. All of this happens in our session facade (stateless session bean):

      for (Iterator i=sd.getMTGroups().iterator(); i.hasNext();) {
      MTGroupLocal mtg = (MTGroupLocal) i.next();
      if (Global.STATUS.ACTIVE == mtg.getStatusId() && mtGroup == mtg.getId().intValue()) {
      return true;
      return false;

      The MDBs consume the messages and are doing a lookup on the same entity (MTGroup) as the precheck. We get the following error:

      18:11:54,618 ERROR [STDERR] javax.ejb.EJBException: null; CausedByException is:
      Application deadlock detected, resource=org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@2baf77, bean=com_afl_srmp_entity_ServiceDetail, id=1, refs=3, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=8246CCFZ10S6//30407, BranchQual=], synched=Thread[RMI TCP Connection(25)-,5,RMI Runtime], timeout=5000, queue=[TXLOCK waitingTx=TransactionImpl:XidImpl [FormatId=257, GlobalId=8246CCFZ10S6//30441, BranchQual=] id=0 thread=Thread[RMI TCP Connection(29)-,5,RMI Runtime] queued=true], holder=TransactionImpl:XidImpl [FormatId=257, GlobalId=8246CCFZ10S6//30465, BranchQual=], waitingResource=org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@cc863, bean=com_afl_srmp_entity_MTGroup, id=1, refs=2, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=8246CCFZ10S6//30331, BranchQual=], synched=null, timeout=5000, queue=[TXLOCK waitingTx=TransactionImpl:XidImpl [FormatId=257, GlobalId=8246CCFZ10S6//30407, BranchQual=] id=0 thread=Thread[RMI TCP Connection(28)-,5,RMI Runtime] queued=true], waitingResourceHolder=TransactionImpl:XidImpl [FormatId=257, GlobalId=8246CCFZ10S6//30331, BranchQual=]

      any ideas and recommendations?

      We are pushing a high load onto the queue using 5 threads (all doing the precheck involving the MTGroup entity)



        • 1. Re: Serious deadlock problem
          gorano Newbie

          Yes I sorted it!

          It was a classical deadlock... (embarrassed)

          Only one question remains:

          Before JMS (seesion bean) I call Entity A and after that Entity B, using transaction required.

          In consumer MDB I call a session bean that calls entity B and after that entity A (my deadlock).

          Setting transactions not supported solved the problem, but I would like to have transactions on this session bean.

          I thought that setting involved entity bean methods to read only would make them not take part in the transaction but this didn't help.

          Any one that cane make this clear to me?



          • 2. Re: Serious deadlock problem
            Ivan O. Parra Novice

            So let me get this right:

            Steps for thread 1
            A) some entry point(client, jsp, other)
            B) Access Entity A
            C) Access Entity B

            Steps for thread 2
            A) JMS
            B) Access Entity B
            C) Access Entity A

            Well, How about applying a policy in your facade that always accesses A before B. That should handle DL issue.

            If that is not an option, you may want to look at OptimisticLocking(Or risk data integrity with NoLock). If you do that, I'd also recommend "Instance Per Transaction". If you plan to cluster or support more than 1 appserver(and are not doing row-locking), you'll have to go in this path anyways. If you are running with a heavy enough load to get DL frequently, you may want to consider that option anyways.