Hello, let me describe the use cases we have in mind for the multiplexing node store in a more detailed way. I hope it’ll allow to plan a few (well, two) milestones for the implementation.
Let’s assume a Sling installation, in which /apps and /libs nodes contains the immutable application code (component, JSPs, etc.) and all the other paths (/content, /var) contain the mutable application state. Our goal here is to extract the application code into a separate “private” repository, while keeping the instance state in the main “global” repo. This gives us two new possibilities: (a) the “private” repository is a low-latency one, so if the “global” repository is shared, distributed and therefore slower, we’ll have fast access to the application code that doesn’t need to be shared, (b) the application can be upgraded to the newer version by simply switching the “private” repository. In order to achieve (a) we need a way to split a normal (“initial”) Sling repository into private and global. It can be done using oak-upgrade: 1) we start a normal Sling instance. The multiplexing node store is not configured yet. 2) once the Sling starts, we stop it and use oak-upgrade to: -copy /apps and /libs to the “private” repository, -copy all the other paths to the “global” repository. 3) we start the Sling again, this time with multiplexing node store configured to support “private” and “global” repository. Since the “private” and “global” repositories are really extracted parts of the same “initial” repository, we don’t need to worry about the consistency - as at the node store level “private” + “global” repository === “initial” repository, which, as we know, is consistent. This scenario (a) is possible to have with the current version of the multiplexing node store patch. That’s why I think it’d be a good idea to document it (putting an emphasis on fact that splitting an existing repository into parts using oak-upgrade is right now the *only* way to get a consistent multiplexing node store repository) and merge. The patch is already quite big and I think that postponing it will make it hard to track the progress here. In order to implement scenario (b) we’ll have to make sure that already existing “global” repository combined with the new “private” repository (created on an alien instance) is still consistent. This is the place where we have to perform all the sanity checks. I’d like, however, to make this the next phase of multiplexing node store implementation, rather than making this a part of the current patch (which is limited as in above, but correct, considering its constraints). WDYT? Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com [email protected] > On 27 Oct 2016, at 09:47, Michael Dürig <[email protected]> wrote: > > > Hi Robert, > > On 26.10.16 11:28 , Robert Munteanu wrote: >> On Wed, 2016-10-05 at 12:13 +0300, Robert Munteanu wrote: >>> >>> Created a sub-task for this >>> >>> OAK-4891 - Mount-time sanity checks for mounted NodeStore >>> instances >>> https://issues.apache.org/jira/browse/OAK-4891 >> >> I've thought about this a little more. When mounting a NodeStore we are >> working (unsurprisingly) at the NodeStore level, so we don't have any >> concept of node types, versions, etc. So I can't use any of the logic >> from oak-jcr, like the VersionManagerImpl. > > This kind of logic is implemented in the various commit hooks. See e.g. > {{org.apache.jackrabbit.oak.plugins.version.VersionHook}}. The sanity checks > should reuse these hooks. > >> >> The only way that I see right now is to use the NodeStore API and >> 'manually' perform the needed checks, e.g. look for nodes with a >> property named 'jcr:mixinTypes' which has a 'mix:referenceable' value. > > Please don't. We need to stay DRY here. Everything else will fall apart going > forward. > >> >> Is this approach a viable one? Also, is this done somewhere else in the >> Oak codebase? I'd like to avoid duplication. > > The intention of the commit hook was to make them pluggable. Have a look at > the Jcr and Oak builder classes and how we actually inject those hooks to > implement the JCR semantics. The sanity checks should follow a similar > approach IMO. > > Michael > >> >> Thanks, >> >> Robert >>
smime.p7s
Description: S/MIME cryptographic signature
