[ApacheDS] [entryDn] We should add it! (was: Re: [ApacheDS] Poor man's cluster interceptor)

[Alex Karasulu <ak...@gmail.com>]

Might be a good idea to add this operational attribute as a virtual
attribute to an entry when it is going out the door ONLY.  We should do it
like this because then we don't have to load up the entry from the backend
when doing modDn operations.  At this point we're totally hosed on modDN
because of the decision to include the DN in the entry.

Incidentally I will have to veto any release that does not fix this problem:
it's high priority IMO. I warned about the performance issue it brings
about. Howard Chu confirmed this and still it's the case. To see just load
up a server with 1M user entries then try a modDN on ou=Users.  Do it on the
server before this change and after it was introduced.  Seeing the
difference will convince anyone.

On Mon, Feb 23, 2009 at 5:30 AM, Emmanuel Lecharny <el...@apache.org>wrote:

> RFC 5020 is trying to fix this, adding a virtual entryDN attribute :
> http://www.rfc-editor.org/rfc/rfc5020.txt
>
> That's not a bad idea. However, I don't know whay using a DN in the
> requetsed attributes should automatically lead to an error. Is there a
> major problem forbiding a server to return a DN as if it were an
> attribute, if specifically requested ?
>
> On Mon, Feb 23, 2009 at 11:23 AM, ayyagarikiran <ay...@gmail.com>
> wrote:
> > I believe the jabber server's LDAP setting is treating the 'dn' as a
> > attribute name (e.x the attribute used for fetching the uid or group
> value
> > ).
>

Re: [ApacheDS] [entryDn] We should add it! (was: Re: [ApacheDS] Poor man's cluster interceptor)

[Emmanuel Lecharny <el...@apache.org>]

Alex Karasulu wrote:
> Might be a good idea to add this operational attribute as a virtual
> attribute to an entry when it is going out the door ONLY. 
We already have it. No need to add this attribute, we just have to get 
the DN from the entry we are manipulating.
>  We should do it
> like this because then we don't have to load up the entry from the backend
> when doing modDn operations.  At this point we're totally hosed on modDN
> because of the decision to include the DN in the entry.
>
> Incidentally I will have to veto any release that does not fix this problem:
> it's high priority IMO. 
I think you are fighting the wrong horse here. It's not a problem, it's 
an optimization.
> I warned about the performance issue it brings
> about. Howard Chu confirmed this and still it's the case. To see just load
> up a server with 1M user entries then try a modDN on ou=Users.  Do it on the
> server before this change and after it was introduced.  Seeing the
> difference will convince anyone.
>   
I agree that for a user doing a moddn every minutes on a 10 million 
entires server, tat might be an issue. Now, considering that moddn is 
_by far_ not the most oftenly used operation on a LDAP server, I don't 
see where the problem is. In fact, I'm pretty sure that it cost the same 
to have the DN in the entry or not (or at least, it has the same cost, 
from the complexity theory pov). I will try to explain it once again :

1) you don't have the DN within the entry
- for EVERY search, you will have to fetch the entry and to fetch the 
DN, in two different tables.
- doing a moddn, you will have to update _all_ the DN which are impacted 
(one per moved entry)

2) you have the DN within the entry
- for EVERY search, you spare a fetch for the DN table
- doing a moddn, you will have to update _all_ the impacted entries - as 
they contains the UpDN and all the NormDN table
- incidentally, you don't have to deal with the UpDN table, as it's now 
useless (it's already present into the entry) : you can spare a table 
and an index. Not to be neglected.

We can discuss this again, I think there are pros and cons in both 
sides. But I'm pretty sure that (2) would be faster for 99% of the cases 
(ie, for a server where a moddn is not a frequent operation.).

I personally doubt that a serious LDAP admin will accept more than a few 
moddn per year. IMHO, this is typically something you do offline when 
reorganizing a base. I may be wrong, though.

I would suggest one thing : we have the Apache Conference in one month, 
a perfect place to discuss this point, as many of us will be there.

I remember having suggested last year that we could let the user decide 
: having the DN stored within the entry could be an option. It won't be 
such a pb to implement this in the server, now that everything is quite 
decoupled right now (we still have the UpDN table, and it's managed, 
plus we need the entryDN to be present, it's just a matter to inject it 
while fetching the entry, instead of deserializing it). So we didn't 
closed any door so far. Maybe a week of work to establish this dual mode.

But I'm ready to bet a bottle of good champagne that option (2) will 
bring better performance for mostly all the operations for an acceptable 
penalty when doing a moddn :)

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org