[
https://issues.jboss.org/browse/ISPN-2361?page=com.atlassian.jira.plugin....
]
Mircea Markus resolved ISPN-2361.
---------------------------------
Resolution: Done
well spotted both issues!
Initially the AbstractCacheTransactions was using an ReentrantLock. That allocated an
additional object per tx but the code was significantly simpler as spurious wake ups were
not possible. Now that we have the correct implementation is better performance wise, as
we allocate fewer objects.
AbstractTxLockingInterceptor.lockKeyAndCheckOwnership() anomalies:
can wait indefinitelly or it can wait too little due to spurious wakeups
-------------------------------------------------------------------------------------------------------------------------------------------
Key: ISPN-2361
URL:
https://issues.jboss.org/browse/ISPN-2361
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.2.0.Alpha4
Reporter: Adrian Nistor
Assignee: Adrian Nistor
Fix For: 5.2.0.Beta1
When waiting for pending locks we can get into 2 cases that are not correctly handled:
1. The check for remaining time (remaining < 0) is incorrect because if remaining == 0
it will try to wait for transactions (waitForLockRelease) with 0 timeout (indefinitely).
2. CacheTransaction.waitForLockRelease() can return earlier than the specified timeout
and the transaction might not yet be complete. This happens because the mechanism inside
waitForLockRelease() does not protect itself from spurious wakeups leaving this to the
caller. AbstractTxLockingInterceptor must be fixed to take care of this.
--
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