[
https://issues.jboss.org/browse/ISPN-2164?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-2164:
----------------------------------------
However, in spite of having a workaround, it's worth considering the need for the
check to see if the key is conditional to add it to the read keys and so do the write
check... investigating.
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