[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1298) Removal of non-existent node leaves invalid tombstone on remote nodes

Brian Stansberry (JIRA) jira-events at lists.jboss.org
Wed Feb 27 16:11:42 EST 2008


     [ http://jira.jboss.com/jira/browse/JBCACHE-1298?page=all ]

Brian Stansberry updated JBCACHE-1298:
--------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130781

Added link to forum thread; discussion of this issue is a fair bit into my monologue. :-)

> 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
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.CR4
>
>
> 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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list