directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject [ApacheDS] [JDBM Partition] Why it's a BAD idea to store the Entry + DN in the master table
Date Thu, 07 Aug 2008 01:50:59 GMT
Hi all,

The ServerEntry stores the DN of the entry.  I think this is good for better
code organization.  However, storing the entry together with it's DN into
the master table is a very bad idea.  The DN should instead be managed in
the NDN and DN indices.

The reason why I'm suggesting this is because modifyDN operations will be
extremely cumbersome when performed on a DN with many children.  It will
require each child and the target entry to be retreived and written to disk
to-from the master just to change it's DN.  Plus we still have the updn and
ndn indices which also get updated so this is wasteful and causes a lot of
unnecessary access operations.  Also note that we can store a lot more DNs
in a cached JDBM page then we can entries.  So this will produce more memory
consumption along with cache turn over.

If the modifyDN operation changes the RDN of the target, a master table
access is unavoidable because the target's RDN attribute in the entry must
change. However the children of the target can avoid a master table
read-write operation since their RDN attributes do not change.  This is
again only avoidable if we do not store the DN in the master.  Ideally you
just want to update the indices when entries are moved around.

I've been against this drive to push the DN into the master table combinded
with the entry from day one along with the drive to remove the NDN and UPDN
indices.  The obvious reason is due to these issues.  I just did not have
the time to clarify exactly why until I started looking into this bug which
was recently introduced:


 *DIRSERVER-1224 <https://issues.apache.org/jira/browse/DIRSERVER-1224>*
As I reviewed the code it was clear what this will cost much more on all the
flavors of ModifyDN operations.  Just imagine a ModifyDN to rename ou=People
to ou=Users if it contains 100M users in it.  I'd recommend we agree to fix
this as recommended then I can push a JIRA on it so this can be fixed in the
future (but before 2.0 since the correction will cause db
incompatibilities).

Alex

-- 
Microsoft gives you Windows, Linux gives you the whole house ...

Mime
View raw message