Locks not being released under Weblogic 10.3 using MVCC lock

[nathanmesser]

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?

[manik]

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?

[nathanmesser]

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).