2 Replies Latest reply on Dec 19, 2008 12:27 PM by Nathan Messer

    Locks not being released under Weblogic 10.3 using MVCC lock

    Nathan Messer Newbie

      Is the issue raised in JBCACHE-923 likely to be an issue with Weblogic using MVCC locking?

      We're using Weblogic 10.3

      We're currently seeing a situation, after a transaction timed out while making a lot of modifications to our cache, where a particular node in the cache is locked.

      The behaviour we're seeing sounds very similiar to the issue raised in JBCACHE-923, and as the last comment mentions that it was hoped to address this issue more fully with MVCC locking, I wondered if the situation could still occur?

      We are using synchronous replication in a cluster, and haven't yet seen this issue in a single instance, if that's relevant.

      Also, is it possible to put a timeout on locks in JBoss cache, so that if this situation occurs, and a lock is left after a transaction has rolledback, the lock will eventually be released?

        • 1. Re: Locks not being released under Weblogic 10.3 using MVCC
          Manik Surtani Master

          JBCACHE-923 is really a workaround to a flawed transaction manager implementation in WLS (TMs are not allowed to let more than one thread access a specific transaction at any given instant, according to the JTA spec), and IIRC you should not see a worker thread processing a transaction and a simultaneous commit or rollback on the same transaction, on a separate thread in WLS 10.

          Can you confirm that this is indeed the case, where a transactions acquires locks and due to a race between further processing and a rollback, the rollback doesn't properly happen and leaves stale/unreleased locks?

          • 2. Re: Locks not being released under Weblogic 10.3 using MVCC
            Nathan Messer Newbie

            I haven't yet been able to reproduce the problem in a controlled manner, although I'm trying.

            All I can confirm at the moment is that we've seen a stale/unreleased lock, reporting that it's held be a transaction that doesn't exist anymore, after having a transaction rolledback by a timeout (I can't even confirm for sure, although it seems very likely, that the transaction that rolledback was the one that obtained the lock).