Re: [RT] Limited write support for non-default CompositeNodeStore mounts
On Thu, 2020-07-09 at 15:35 +, Marcel Reutegger wrote: > Hi, > > On 09.07.20, 15:39, "Robert Munteanu" wrote: > > The details are rough and my memory of the implementation is not > > that > > good > > Same here. > > Besides the problem with a potential two phase commit, I think the > biggest concern was impact of a change in a mounted subtree on > repository wide data structures. E.g. what happens when an access > control entry is added to such a subree? How are indexes updated for > nodes changed in the subtree? Well, it depends. The current check when merging changes is simple - only allow them to the default (read-write) mount. What I propose is allow writes to all mounts under given circumstances. For instance (all examples inside a non-default mount): - if there is an observation listener that should be triggered, fail the commit - if an index should be updated and we know we can't do that, fail the commit The downside is that it is less predictable that a 'plain' read-only situation and can be confusing for users of the repository. Or that, due to the way the repository is configured, effectively no changes can be persisted ( e.g. observation listener for all of /apps ). > > I'm also wondering whether and where the current implementation > assumes > mounted subtrees are read-only and takes short cuts. These would need > to > be changed as well. Yes, those implementations need to be revisited as well. I am a bit optimistic here since for instance indexing can write to a separate location; this is one of the steps of preparing a composite node store. Thanks, Robert
Re: [RT] Limited write support for non-default CompositeNodeStore mounts
Hi, On 09.07.20, 15:39, "Robert Munteanu" wrote: > The details are rough and my memory of the implementation is not that > good Same here. Besides the problem with a potential two phase commit, I think the biggest concern was impact of a change in a mounted subtree on repository wide data structures. E.g. what happens when an access control entry is added to such a subree? How are indexes updated for nodes changed in the subtree? I'm also wondering whether and where the current implementation assumes mounted subtrees are read-only and takes short cuts. These would need to be changed as well. Regards Marcel
[RT] Limited write support for non-default CompositeNodeStore mounts
Hi, I've been thinking about the read-only aspect of the CNS, and whether it would be useful to relax this constraint. The primary driver (in the Sling world) is that while content packages and repoinit allow easy inspection of the payload so we can know ahead of time if anyone would write to a non-default mount ( e.g. /apps ) there are two wildcards: - bundle activators and OSGi components - vault hooks We cannot be sure that none of them will write in the repository in a non-default mount, and for the sake of compatibility we could allow writing. There are two major constraints listed in the CNS documentation [1]: - atomic commits across node stores - oak subsystems that are not composite-aware I would propose that we 'solve' these problems in the following ways: 1. Allow commits only over individual node stores, never commits that span multiple stores 2. Validate that subsystems that are not composite-aware are not affected. For instance, that no observation listeners are bound to paths under non-default mounts. The details are rough and my memory of the implementation is not that good, but I would like to see what others think before committing to a POC. Thanks! Robert [1]: https://jackrabbit.apache.org/oak/docs/nodestore/compositens.html
