[ 
https://issues.apache.org/jira/browse/DIRSERVER-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542964
 ] 

Alex Karasulu commented on DIRSERVER-465:
-----------------------------------------

With a single nexus that itself cannot store entries the server is severely 
constrained. 

(1) We cannot have subentries under the RootDSE so the RootDSE cannot be an 
administrative point.
(2) The RootDSE must be read only and cannot be dynamically changed even by the 
admin.
(3) A parent with millions of children who themselves have millions of children 
cannot be partitioned separately from it's children which leads to performance 
and capacity issues.
(4) Aliases are not allowed across partitions and so linking entries in 
different domains via aliases is not possible and may be required to share 
users or groups across domains.
(5) The number of out of the box partitions is growing (ou=system, ou=schema); 
What's next?
(6) The alias problem can be solved by a nexus that can store entries; it can 
consolidate and track alias indices across nested partitions.

This is something that should be addressed before the bigbang completes.

> Use multiple PartitionNexus' for layered partitioning
> -----------------------------------------------------
>
>                 Key: DIRSERVER-465
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-465
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>          Components: core
>            Reporter: Alex Karasulu
>            Assignee: Alex Karasulu
>            Priority: Minor
>             Fix For: bigbang
>
>
> I just got a great idea but it might be a little crazy.  There is a problem 
> with the current model where there can only be one (singleton) nexus way at 
> the top of a system.  This severly limits how the namespace can be 
> partitioned.  Because of BackingStore operation routing concerns to 
> ContextPartitions, one cannot have two ContextPartitions having a suffix 
> overlap.  Basically ContextPartitions with suffixes like so are not allowed:
> ..o CP1 suffix is dc=apache,dc=org
> ..o CP2 suffix is ou=people,dc=apache,dc=org
> Here's how the tree might look:
> .............................[RootNexus]
> ................................/...\
> ............................[CP1]...[CP2]
> The suffix of CP1 overlaps the suffix of CP2.  Basically requests recieved 
> under the CP2 suffix base have a tough time determining where they should 
> route calls.  To avoid this confusion there is the restriction mentioned 
> above.
> What if had a very special kind of nexus that was not a singleton and had a 
> suffix associated with it?  Furthermore this nexus can contain entries off of 
> that suffix as well instead of just delagating their storage to partitions it 
> bridges.  This nexus could then eliminate the routing problem and remove the 
> restriction.  For the time being lets call this a ContextNexus.  So we could 
> have the following configuration:
> ..o CN1 suffix is dc=apache,dc=org
> ..o CP2 suffix is ou=people,dc=apache,dc=org
> Here's how the tree might look:
> .............................[RootNexus]
> ..................................|
> ................................[CN1]
> ..................................|
> ................................[CP2]
> Here in this case entries like ou=groups,dc=apache,dc=apache and its contents 
> would be stored in CN1 and so would the suffix dc=apache,dc=org.  Now because 
> of this extra level of routing decisions for routing cannot get confusing.   
> We can then partition the namespace in any manner we see fit with minimal 
> cost to performance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to