[
https://issues.apache.org/jira/browse/OAK-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-3402:
-------------------------------
Component/s: (was: segment-tar)
(was: documentmk)
core
> Multiplexing NodeStore support in Oak layer
> -------------------------------------------
>
> Key: OAK-3402
> URL: https://issues.apache.org/jira/browse/OAK-3402
> Project: Jackrabbit Oak
> Issue Type: Epic
> Components: core
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Labels: multiplexing
>
> Supporting multiplexing repository would have impact on various places in Oak
> design. There are various sub components in Oak which maintain there own
> storage built on top of NodeStore. For e.g. indexes are stored within
> NodeStore, permissions are also stored within NodeStore. Adding multiplexing
> support would impact such stores in following ways
> The most basic application of multiplexing support is to support private and
> shared storage. Under this an Oak application would have a private store and
> a shared store. Content under certain paths would be stored under private
> repo while all other content is stored under shared repo
> # *Writing* - Any content written via JCR API passes through some
> {{CommitHooks}}. These hooks are responsible for updating the indexes,
> permission store etc. Now if any path say /foo/bar gets modified the commits
> hooks would need to determine under which path in NodeStore should the
> derived data (index entries, permission etc) should be stored. For simple
> case of private and shared store where we have 2 sets of paths private and
> shared these hooks would need to be aware of that and use different path in
> NodeStore to store the derived content. Key point to note here that any such
> storage has to differentiate wether the path from which the content is being
> derived is a private path or shared path
> # *Reading* - Reading requirement compliments the writing problem. While
> performing any JCR operation Oak might need to invoke QueryIndex,
> PermissionStore etc. These stores in turn would need to perform a read from
> there storage area within NodeStore. For multiplexing support these
> components would then need to be aware that there storage can exist in both
> shared and private stores
> h4. Terms Used
> # _private repo_ (PR) - Set of paths which are considered private to the
> application. Tentative example /lib,/apps
> # _shared repo_ (SR) - Set of paths which are considered shared and different
> versions of the application can perform read and write operations on them.
> Tentative example /content, /etc/workflow/instances
> # {{PathToStoreMapper}} - Responsible for mapping a path to store type. For
> now it can just answer either PR or SR. But the concept can be generalized
> Aim of this story is to prototype changes in Oak layer in a fork to asses the
> impact on current implementation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
