[jbosscache-dev] Fixing MVCC(RC) + UnversionedNode for PCACHE-82

Galder Zamarreno galder.zamarreno at redhat.com
Wed Jun 24 11:32:39 EDT 2009


Hi all,

Re: https://jira.jboss.org/jira/browse/PCACHE-82

Even though this is not urgent, it's a good exercise for me to get a 
better understanding of MVCC and hence why I decided to finally tackle it.

I've been trying to figure out what exactly is the bug in this JIRA. 
I've created a test case that reproduces the bug (attached). The issue 
is clearly related to MVCC(ReadCommitted) and UnversionedNode instances 
but I'm failing to understand what the fix exactly is.

Let me sum up what happens internally (note that a lot of the 
information below is from logging statements I added):

1. Create a Person, Galder, and attach it under 
/person/testDoubleAttachAndDetach
2. Create a Person, Asier, and attach it in the same fqn.
3. In the 2nd attachment, ReadCommittedNode.markForUpdate() backs up the 
NodeReference for /person/testDoubleAttachAndDetach creates a copy of 
the UnversionedNode representing underneath.
4. More importantly, because calling attach the 2nd time means detach 
needs to happen before to remove the old value, so 
MVCCNodeHelper.wrapNodesRecursivelyForRemoval() executes the addChild() 
below:

// update child ref on parent to point to child as this is now a copy.
if (parentLockNeeded && (needToCopyNode || needToCopyParent)) {
   if (parent == null) throw new NodeNotExistsException("Parent node " + 
parentFqn + " does not exist!"); 
parent.getDelegationTarget().addChild(node.getDelegationTarget());
}

This leads to adding the UnversionedNode version of 
testDoubleAttachAndDetach to /person node's children.

5. At the end 2nd attachment, ReadCommittedNode.updateNode() method 
takes the backup (NodeReference) and the node (UnversionedNode) and 
swaps them again but the parent's children, /person, is still pointing 
to an UnversionedNode which leads to the ClassCastException that you see 
when you execute the test.

I'm not sure what really should be happening here since I don't 
understand the rationaly of that addChild() call. Should it be happening 
at all in this case? Or maybe a corrective action of some sort needs to 
be done somewhere?

Thanks for the help in advance!
-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AttachDetachTest.java
Type: text/x-java
Size: 4568 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20090624/bb857f4f/attachment.bin 


More information about the jbosscache-dev mailing list