directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <directory-...@incubator.apache.org>
Subject [jira] Updated: (DIREVE-23) Use multiple PartitionNexus' for layered partitioning
Date Sat, 27 Nov 2004 16:06:21 GMT
     [ http://nagoya.apache.org/jira/browse/DIREVE-23?page=history ]

Alex Karasulu updated DIREVE-23:
--------------------------------

    Priority: Minor  (was: Major)

> Use multiple PartitionNexus' for layered partitioning
> -----------------------------------------------------
>
>          Key: DIREVE-23
>          URL: http://nagoya.apache.org/jira/browse/DIREVE-23
>      Project: Directory Eve
>         Type: Improvement
>   Components: jndi-provider
>     Reporter: Alex Karasulu
>     Assignee: Alex Karasulu
>     Priority: Minor

>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message