jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: When moving a Tree, can it die?
Date Fri, 05 Oct 2012 07:58:59 GMT

Hi,

On 4.10.12 16:34, Jukka Zitting wrote:
>      Tree r = root.getTree("/");
>          Tree x = r.getChild("x");
>          Tree y = r.getChild("y");
>
>          root.move("/x", "/y/x");
>          assertEquals("y", x.getParent().getName());
>
> To avoid this problem, I'm wondering if we could allow a Tree instance
> that was acquired before the move to become invalid or "disconnected"?
> Any changes to a Tree instance in such a sate would just be discarded
> and the return values of methods like getParent() or getLocation()
> would be undefined (typically returning the values they had before the
> move).

That behaviour is already there in the case of Root.refresh() and 
Root.commit() being called. See the respective Javadoc. In this case 
getPath() on an invalid Tree instance returns the "previous" value. This 
is currently used to re-resolve JCR Items after refresh/commit. However 
in the case of a move operation I think this would cause the above test 
case to fail, since x.getParent() would then still point to the root. 
Maybe we could just throw an InvalidItemStateException for such cases? 
This would simplify things considerably, let us get rid of the children 
weak refs, and might also open up a way to reduce the number of 
re-resolves taking place. As Marcel pointed out yesterday, the latter 
also shows up as bottleneck in read performance.

Michael

Mime
View raw message