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.
Michael
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
