jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-3402) Multiplexing DocumentStore support in Oak layer
Date Tue, 03 Nov 2015 10:36:27 GMT

     [ https://issues.apache.org/jira/browse/OAK-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

angela updated OAK-3402:
------------------------
    Component/s: documentmk

> Multiplexing DocumentStore support in Oak layer
> -----------------------------------------------
>
>                 Key: OAK-3402
>                 URL: https://issues.apache.org/jira/browse/OAK-3402
>             Project: Jackrabbit Oak
>          Issue Type: Story
>          Components: documentmk
>            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)

Mime
View raw message