3 Replies Latest reply on Sep 21, 2004 12:38 PM by elidaniel

    Deadlock in AbstractInstanceCache.tryToPassivate()

    elidaniel Newbie

      I am running into what's listed as bug 987389 on sourceforge. Scott Stark says:

      The problem is inconsistent
      acquisition order of the two locks, m_cacheLock and cache id
      BeanLock.

      AbstractInstanceCache.get
      -> synchronizes(m_cacheLock)
      -> CachePolicy.insert()
      ...
      -> LRUEnterpriseContextCachePolicy.ageOut
      -> AbstractInstanceCache.release
      -> AbstractInstanceCache.tryToPassivate
      -> BeanLock.sync()
      + deadlocked waiting for BeanLock

      LRUEnterpriseContextCachePolicy$OveragerTask.run
      -> AbstractInstanceCache.tryToPassivate
      -> BeanLock.sync()
      -> synchronizes(m_cacheLock)
      + deadlocked waiting for m_cacheLock


      The bug is closed, marked Fixed for 3.2.6RC2.

      I am very interested in the fix for this bug, because I am running into deadlocks quite frequently, and would like to patch my 3.2.3 server. However, I cannot find this fix in CVS. There have been no recent changes to either AbstractInstanceCache or LRUEnterpriseContextCachePolicy that look relevant. An inspection of the code from the 3.2.6RC2 branch in CVS reveals the same problem... nothing at this level appears to have changed.

      So, can someone kindly clarify what the status of this is? If it was fixed somewhere deeper, can you point me at the relevant change so I can apply a patch to my server? If the fix has not yet been submitted to CVS, can you provide an ETA for it?

      Thanks,
      Eli Daniel