[
https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-3558:
-------------------------------------
The provided test case should indeed fail.
The reason being is that putForExternalRead is invoked outside of any current transaction
using putIfAbsent semantics. So in this case the current tx is suspended and a
putIfAbsent is invoked in which case it fails since the value is still technically there
since it isn't done in the tx that has a clear. Afterwards the original tx is resumed
and the get returns nothing since the clear has removed it in it's context.
# Currently clear takes out locks (if needed) and stores in the context any values it was
clearing out. This means that if a a new entry is committed after clear is invoked (not
yet committed) that you can use get to retrieve it since the clear didn't see that
value (kinda like a write skew we don't detect).
# PFER does a putIfAbsent so the cache must not contain that value for it to work
I will add some test cases to verify these behaviors for the JIRA though.
PutForExternalRead won't work after a clear(), when both in same
tx
-------------------------------------------------------------------
Key: ISPN-3558
URL:
https://issues.jboss.org/browse/ISPN-3558
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.3.0.Final, 6.0.0.Beta1
Reporter: Galder ZamarreƱo
Assignee: William Burns
Fix For: 6.0.0.CR1, 6.0.0.Final
{code}
public void testPutForExternalReadAfterClear() throws Exception {
cache.put(1, "v1");
tm().begin();
try {
cache.getAdvancedCache().clear();
cache.putForExternalRead(1, "v1");
assertEquals("v1", cache.get(1));
} finally {
tm().commit();
}
}
{code}
--
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