[
https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin....
]
Pedro Ruivo commented on ISPN-2013:
-----------------------------------
Hi [~dudalov]. can you tell me your use case?
Although I think that it is bad to allow the programmer to unlock locks in the middle of
the transaction, I've made some changes to allow it. However, your tests is reporting
inconsistencies (java.util.ConcurrentModificationException: Cache inconsistent:
value=value, nextValue=value-1) that make sense to happen because you're releasing a
lock before the transaction commit. So the next TX will see old values from some keys and
new values for other keys. That's why I'm asking for your use case.
Using explicit "unlock" causes TimeoutException for other
Threads
-----------------------------------------------------------------
Key: ISPN-2013
URL:
https://issues.jboss.org/browse/ISPN-2013
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 5.1.2.FINAL
Environment: Windows 7 64-bit
Reporter: Dmitry Udalov
Assignee: Pedro Ruivo
Fix For: 6.0.0.Final
Attachments: LockTest.java
In a test I have several tasks that run on a single cache node configured as
transactional pessimistic replicated cache. If I explicitly call "unlock" then I
consistently see TimeoutException reported by some tasks. Without explicit
"unlock" the test works fine. Does it mean that I should never call
"unlock" and rely on transaction.commit/rollback ? It's seen with
infinispan-5.1.2.FINAL
Here's what in a nutshell each task does:
final lockKey = ...
executor.submit(new Callable<Boolean>() {
public Boolean call() throws Exception
TransactionManager tx = cache.getAdvancedCache().getTransactionManager();
tx.begin()
try {
if ( lockManager.lock(lockKey) ) {
// ...
// removing next line makes test happy. Otherwise some tasks report
TimeoutException (pls. see the stack traces)
cache.getLockManager().unlock(lockKey);
}
} catch(Throwable t) {
tx.setRollbackOnly();
} finally {
if (ut.getStatus() == Status.STATUS_ACTIVE)
ut.commit();
else
ut.rollback();
}
By the time I received that exception all other tasks were completed and they released
the lock on the key in question.
I also see that LockManagerImpl.lock recognized that the lock was not owned by any thread
- see "Lock held by [null]", which seems to be right. But yet the lock failed to
be acquired.
Is it a matter to trying it one more time?
org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10
seconds] on key [foo] for requestor [GlobalTransaction:<Sound-15075>:8:local]! Lock
held by [null]
at
org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:206)
at
org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:180)
at
org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:170)
at
org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209)
at
org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136)
at
org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:228)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at
org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:144)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:207)
at
org.infinispan.interceptors.StateTransferLockInterceptor.visitLockControlCommand(StateTransferLockInterceptor.java:138)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at
org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130)
at
org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:94)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
at org.infinispan.CacheImpl.lock(CacheImpl.java:484)
at org.infinispan.CacheImpl.lock(CacheImpl.java:468)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira