jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Inconsistent locking in TreeImpl.Children?
Date Thu, 30 Aug 2012 13:41:06 GMT

On Thu, Aug 30, 2012 at 3:09 PM, Marcel Reutegger <mreutegg@adobe.com> wrote:
> The JavaDoc currently says that it is not thread-save for writing, but
> it is for reading.

See the discussion at http://markmail.org/message/m7linbldpirjz2bn for
background on the thread-safety bit. My original proposal was *not* to
make thread-safety guarantees on Tree, but others felt that some level
of thread-safety would be useful. I think we'll need to revisit that
later on once we see how much of a performance and complexity hit that

> It also seems the locking is a left over from the previous children
> implementation class that was used before Oak switched to Google
> Guava. Previously it was using ReferenceMap, which is not thread-safe,
> but the current implementation *is* thread-safe. See JavaDoc of
> Cache.asMap(). I think the locking can be removed from Children.

Ultimately I think we should get rid of the child node cache in
TreeImpl and instead rely on the underlying NodeState(Builder) for
that, especially now with the nice MemoryNodeStateBuilder child node
tracking mechanism that doesn't need weak references.


Jukka Zitting

View raw message