[jbosscache-issues] [JBoss JIRA] Commented: (JBCACHE-1493) REPEATABLE_READ inconsistent with write skew disabled
[
https://jira.jboss.org/jira/browse/JBCACHE-1493?page=com.atlassian.jira.p...
]
Manik Surtani commented on JBCACHE-1493:
----------------------------------------
Actually, this is an edge case - and only happens if the node did not exist in the first
place. The test above doesn't prove this; the following test does:
// start with an empty cache
tm.begin();
cache.getNode("/a");
Transaction tx = tm.suspend();
cache.put("/a", "k", "v2");
assert cache.get("/a", "k").equals("v2");
tm.resume(tx);
cache.removeNode("/a");
tx.commit();
assert cache.getNode("/a") == null; // this fails
REPEATABLE_READ inconsistent with write skew disabled
-----------------------------------------------------
Key: JBCACHE-1493
URL: https://jira.jboss.org/jira/browse/JBCACHE-1493
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking
Affects Versions: 3.0.3.GA
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 3.1.0.GA
Inconsistent in that with a put(), we have the last tx winning and overwriting state,
which is allowed if write skew checking is disabled.
If we have a concurrent put() and removeNode(), this is a problem since the removeNode()
would only remove a node read earlier in the same transaction and not the new, updated
node.
E.g.,:
cache.put("/a", "k", "v");
tx.begin();
cache.get("/a");
tx.suspend();
cache.put("/a", "k", "v2");
tx.resume();
cache.removeNode("/a");
tx.commit();
// node still exists!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira