[
http://issues.apache.org/jira/browse/JCR-169?page=comments#action_12316038 ]
Walter Raboch commented on JCR-169:
-----------------------------------
NodeTypeRegistry:
As mentioned in my comment (15/Jul) I prefer some sort of config management
("Config - the cluster should have a central place for config management ").
NodeType definitions are config data in my understanding.
Access mgr:
We plan to implement some access manager for our project based on ACL objects
saved as nodes in the repository. Because the persistence and observation
manager are cluster aware, changes to the ACLs are distributed to all nodes.
The access manager does not have to care. Or do I miss some point?
> Make Jackrabbit clusterable
> ---------------------------
>
> Key: JCR-169
> URL: http://issues.apache.org/jira/browse/JCR-169
> Project: Jackrabbit
> Type: New Feature
> Components: core
> Reporter: Marcel Reutegger
> Priority: Minor
>
> This jira issue discusses the technical implications on the current design of
> Jackrabbit to introduce clustering.
> Particularly the following areas require thorough investigation:
> - SharedItemStateManager and its cache
> - cache integrity
> - cache design: look aside, write through?
> - hook for distributed cache, interface?
> - isolation level
> - transaction integrity within Jackrabbit, interaction with transient
> layer
> - VirtualItemStateProvider
> - same strategy as SharedItemStateManager?
> - Search index
> - single or per cluster node index?
> - Observation
> Please state more areas if needed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
