[
https://issues.jboss.org/browse/ISPN-2164?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-2164:
-----------------------------------
Git Pull Request:
https://github.com/infinispan/infinispan/pull/1220 (was:
https://github.com/infinispan/infinispan/pull/1220)
Workaround Description:
Basically, the problem comes from cache.remote(k) not doing a write skew check whereas the
conditional remove does. So, a workaround for this is to do a cache.get() before
cache.remove(k), i.e.
{code}if (useConditionalRemove) {
success = cache.remove("k1", "v1");
} else {
cache.get("k1");
success = cache.remove("k1") != null;
}{code}
Workaround: Workaround Exists
Forum Reference:
https://community.jboss.org/thread/202721 (was:
https://community.jboss.org/thread/202721)
Return value of Cache.remove(key) not consistent in transactional
context
-------------------------------------------------------------------------
Key: ISPN-2164
URL:
https://issues.jboss.org/browse/ISPN-2164
Project: Infinispan
Issue Type: Bug
Components: Core API, Transactions
Affects Versions: 5.1.5.FINAL
Reporter: Carsten Lohmann
Assignee: Mircea Markus
I have a scenario where multiple threads attempt to remove the same key concurrently via
"cache.remove(key)" (each thread having explicitly started a transaction).
I expect only one thread to succeed, ie. only one invocation of
"cache.remove(key)" to return a non-null value.
But that is not the case, the return value of "cache.remove(key)" is non-null
for more than one thread.
In that sense, "cache.remove(key)" seems to behave differently from
"cache.remove(key, value)".
The bug can be reproduced by using a test analogous to the one in "DummyTxTest"
(ISPN-2077), but using "cache.remove(key)" instead of "cache.remove(key,
value)".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira