[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1256) PessimisticLockInterceptor does not clean up all temporary nodes created during a removeNode() call

[Manik Surtani (JIRA)]

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

Manik Surtani updated JBCACHE-1256:
-----------------------------------

        Summary: PessimisticLockInterceptor does not clean up all temporary nodes created during a removeNode() call  (was: Data gravitation cleanup results in data owner containing a backup region for self)
    Component/s:     (was: Buddy Replication)
    Description: 
This was probably introduced with JBCACHE-1165 - which involved creating nodes that do not exist when removeNode() is called, so that appropriate locks can be obtained to prevent concurrent remove and add race conditions.

The issue is that while the temporary node created is deleted as a part of the removeNode() call, temporary nodes created in the process (structural nodes) are not cleaned up.

testPhantomStructuralNodesOnRemove() and testPhantomStructuralNodesOnRemoveTransactional() in CacheAPITest (and CacheAPIOptimisticTest) depict this behaviour.

One side effect is incorrect data gravitation cleanup, as depicted by gravitation cleanup calls resulting in data owner containing a backup region for itself.

See unit test for this gravitation side-effect:

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/core/trunk/src/test/java/org/jboss/cache/buddyreplication/GravitationCleanupTest.java?view=markup


  was:
See unit test for this:

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/core/trunk/src/test/java/org/jboss/cache/buddyreplication/GravitationCleanupTest.java?view=markup

     Complexity: High  (was: Medium)
       Priority: Critical  (was: Major)

> PessimisticLockInterceptor does not clean up all temporary nodes created during a removeNode() call
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1256
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1256
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.0.CR2
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>            Priority: Critical
>             Fix For: 2.1.0.CR3
>
>
> This was probably introduced with JBCACHE-1165 - which involved creating nodes that do not exist when removeNode() is called, so that appropriate locks can be obtained to prevent concurrent remove and add race conditions.
> The issue is that while the temporary node created is deleted as a part of the removeNode() call, temporary nodes created in the process (structural nodes) are not cleaned up.
> testPhantomStructuralNodesOnRemove() and testPhantomStructuralNodesOnRemoveTransactional() in CacheAPITest (and CacheAPIOptimisticTest) depict this behaviour.
> One side effect is incorrect data gravitation cleanup, as depicted by gravitation cleanup calls resulting in data owner containing a backup region for itself.
> See unit test for this gravitation side-effect:
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/core/trunk/src/test/java/org/jboss/cache/buddyreplication/GravitationCleanupTest.java?view=markup

-- 
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