jackrabbit-dev mailing list archives

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

Stefan Guggisberg 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.

the NodeTypeRegistry is mutable. new node types can be registered at runtime. all nodes in
a cluster 
must be informed on changes in the NodeTypeRegistry.

> 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?

if you're AccessManager implementation reads the ACL's from repository content i assume it
caches 
the ACL's for better performance. your AccessManager must be therefore aware of changed ACL's
and flush its cache accordingly.

btw: managing ACL's in content inevitably leads to chicken&egg kind of problems and generally

require nasty hacks.

versioning subsystem and ref integrity mgmt need to be cluster-aware as well.

> 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


Mime
View raw message