[ http://issues.apache.org/jira/browse/JCR-169?page=comments#action_12316041 ]
Walter Raboch commented on JCR-169: ----------------------------------- NodeTypeRegistry: you are right. The manager must be informed of changes and react on them. I just thought on the ObservationManager which sends the change event to all nodes and thus must be cluster aware. I forgot about the listeners - but this event code in the listeners is not cluster specific. ACLs: Again the same - just a listener of the ObservationManager. I love ACLs in content - especially in our current project - our rules are based on properties of the content nodes. e.g. allow R to all nodes of type comment. allow RW on all nods of type comment and author=CURRENT_USER > 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
