[ 
https://issues.apache.org/jira/browse/OAK-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739694#comment-13739694
 ] 

Thomas Mueller commented on OAK-855:
------------------------------------

As [~alex.parvulescu] wrote, equals is called when committing. This is for 
example a problem when trying to add a child node to a node with many 
(millions) of child nodes, at least with the MongoMK, because it causes all 
other nodes to be loaded and traversed. The test case 
ManyChildrenIT.sizeTest(), ModifiedNodeState.equals is called, which is not 
implemented, so that AbstractNodeState.equals is called.

Possibly ModifiedNodeState.equals could be implemented in a way that avoids 
loading all child nodes.

I would like to change the method name "equals" to something else, for example 
to "isSameAs" or similar. This is to simplify listing the usages (Eclipse isn't 
good at finding usages of "equals"), and because we don't implement "hashCode". 
What is your preferred method name?
                
> NodeState.equals is sometimes very slow
> ---------------------------------------
>
>                 Key: OAK-855
>                 URL: https://issues.apache.org/jira/browse/OAK-855
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Thomas Mueller
>
> The method NodeState.equals seems to be very slow sometimes, for example if a 
> KernelNodeState is compared against a ModifiedNodeState. A recursive 
> traversal is used in this case. I found this problem when running the 
> integration tests (-PintegrationTesting). I guess it's specially a problem if 
> there are many child nodes.
> I wonder if we could use a shortcut when comparing a ModifiedNodeState 
> against a non-modified one: isn't by definition the ModifiedNodeState _never_ 
> equal to a non-modified one, unless there are no changes? 
> When comparing two ModifiedNodeState objects (not sure if that's a common use 
> case), then a simple optimization would also be possible.
> What's also not nice is: it seems multiple NodeState classes implement 
> equals, but not hashCode. Instead of overriding the equals method, I wonder 
> if we should use another mechanism.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to