[ https://issues.apache.org/jira/browse/OAK-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated OAK-3402: --------------------------------- Issue Type: Epic (was: Story) > Multiplexing NodeStore support in Oak layer > ------------------------------------------- > > Key: OAK-3402 > URL: https://issues.apache.org/jira/browse/OAK-3402 > Project: Jackrabbit Oak > Issue Type: Epic > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra > > 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)