]
Manik Surtani resolved JBCACHE-1298.
------------------------------------
Resolution: Done
Removal of non-existent node leaves invalid tombstone on remote
nodes
---------------------------------------------------------------------
Key: JBCACHE-1298
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1298
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Replication, Optimistic Locking
Affects Versions: 2.1.0.CR3
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.1.0.GA
Problem with optimistic locking and invalidation:
Say node with Fqn "/a" doesn't exist in memory in any cache in cluster.
On node1, call to cache.removeNode("/a") is made. This is a valid call even
though "/a" doesn't exist in the local cache -- caller wants it
removed/invalidated across the cluster.
This results in an invalidate() call around the cluster for "/a". Since
"/a" doesn't exist, no DataVersion is passed with the call.
On other nodes in the cluster, the invalidate() method detects that "/a"
doesn't exist locally. So, invalidate() creates a tombstone for "/a".
Tombstone gets initialized with a DefaultDataVersion. Since no other DataVersion was
passed with the call, the tombstone gets left with that DefaultDataVersion.
Now on node2 an attempt is made to do a put to "/a", passing in a DataVersion.
The put fails with a version conflict due to the presence of the tombstone.
InvalidationInterceptorTest.testAddOfDeletedNonExistent() shows the problem. This same
issue is coming up in the Hibernate/JBC integration tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: