Hi Michael, On Mon, 2016-10-03 at 09:15 +0200, Michael Dürig wrote: > Hi Robert, > > As this is a rather big pull request I think it would be good to > shed > some light on the background: > > * What are the use cases / driver you have in mind for this feature? > I > would like to document these early on to avoid mission creep.
>From my point of view there are two main scenarios: 1. Combining a global store with a local one When using a clustered DocumentStore instance it is sometimes useful to have parts of the repository private to the instance - not shared. For example, in Sling land, this would make rolling deployments possible by making /libs and /apps private. 2. Faster container-based deployment by only packaging part of the repository in the container image When building container images the size and startup time should be closely controlled. By allowing NodeStore multiplexing we can package only /libs and /apps into the image and allow the rest of the repository to live outside the container image. > > * Where are the limitation and how are we going to deal with them? > Specifically: how do you deal with atomicity when multiple node > stores > are mounted? Similarly, how do you guarantee global constraints > (like > uniqueness). We explicitly set write multiplexing as a non-goal. This works for now as a side-effect - it was too easy to implement :-) So we will have at most ( usually exactly ) one store which is write- enabled, and all other stores will be read-only. In the scenarios above, /libs and /apps will be read-only. At a JCR level we will make sure that the mounted repositories, except the global one, will have no 'troublesome' nodes: no versioning, no referenceable nodes, etc. > * How is (un)mounting handled? How do you ensure the node store > satisfy > all higher level constraints? Mounting is configured via OSGi and expected to not change at runtime. Doing this dynamically is a non-goal. As for the other high-level constraints, a read-only mount with limited JCR capabilities in terms of versioning, locking, etc should not pose any issues. Can you maybe add some specific scenarios that you think can be problematic? Thanks, Robert > > Michael > > > > On 30.9.16 3:45 , Robert Munteanu wrote: > > Hi, > > > > I've submitted a pull request for a multiplexing NodeStore based on > > the > > work done my Tomek and myself. > > > > https://github.com/apache/jackrabbit-oak/pull/55 > > https://issues.apache.org/jira/browse/OAK-4871 > > > > While it's not 100% done ( see Jira/PR for more details ) I believe > > that since it's isolated from the rest of the code base it would be > > beneficial for further maintenance and a high-level design check to > > submit it early rather than when it's 'done'. > > > > Comments towards what is still needed to actually incorporate it in > > oak-core would be very appreciated. > > > > Thanks, > > > > Robert > >
