jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Walter Raboch (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-169) Make Jackrabbit clusterable
Date Mon, 18 Jul 2005 15:03:13 GMT
    [ http://issues.apache.org/jira/browse/JCR-169?page=comments#action_12316041 ] 

Walter Raboch commented on JCR-169:

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

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:
For more information on JIRA, see:

View raw message