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: Oak API - a top down look
Date Wed, 18 Apr 2012 09:23:33 GMT

On 18.4.12 8:06, Jukka Zitting wrote:
>>> All `ContentRepository` and `ContentSession` instances are thread-safe.
>>> ...
>>> `ContentTree` instances are *not* thread-safe...
>> I think it is a good thing to clearly state thread-safe-ness. But I am worried
>> about ContentTree not being thread-safe..
> By declaring as not thread-safe, we avoid having to worry about
> synchronization and concurrent access in a lot of fairly complicated
> bits of code (refresh, commit, etc.). And since a client can easily
> acquire any number of parallel ContentTree instances, ensuring
> thread-safety shouldn't be a problem for the client.

I agree with most of that. However since there will be most likely a 
single Session implementation accessing a ContentTree instance we might 
want to give a bit of a stronger guarantee wrt. threading and make 
ContentTree instances not thread safe for write access but thread safe 
for read access.


>>>     ContentTree tree = ...;
>>>     ContentTree subtree = tree.addSubtree("hello");
>>>     subtree.setProperty("message", "Hello, World!");
>>>     tree.commit();
>> Particularly this one worries me most: We are now leaving the turf of immutable value
>> objects again and enter concurrency problem prone terrain ...
> As mentioned above, these trees are only mutable by the client, so
> there's no need to worry about concurrent changes from elsewhere. So
> for example traversing through the content tree will never encounter
> concurrent changes unless the client itself modifies things. And the
> underlying content model at the MicroKernel level is still fully
> immutable.
> BR,
> Jukka Zitting

View raw message