directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] What about associating the Long id of an entry within ServerEntry
Date Tue, 13 May 2008 06:26:05 GMT
Alex Karasulu wrote:
> Some operations in the default partition based on JDBM would gain a 
> performance advantage if we could stuff the (partition unique) Long id 
> associated with the entry into the ServerEntry object. 

Are you sure? From the top of my head, I don't see how having such a 
value within the ServerEntry object could help. Do you have an exemple ?

(I'm not saying that it's a bad idea, I just can't see where it can 
help. Btw, it would be a no brainer to add such a field)
> Eventually some schemes we discussed in the past for making this Long 
> id a server unique rather than partition unique identifier will come 
> to pass.  At that point we can rapidly compare entries based on this 
> identifier.  Besides the id we will probably eventually have the UUID 
> which is globally unique for the entry across server instances.  
> However the UUID costs more to compare than a long which can be 
> compared in just a few JVM operations.
We need this UUID at some point. It's already used for replication, and 
can be set in any case, as an operational attribute, with a different 
handling : I suggest it's not set as an attribute internally, or at 
least that we have a direct access to this value without having to look 
into the EntryAttribute list. Something like :

class ServerEntry {
  ServerEntryAttribute attributes;
  UUID uuid; // May be duplicated with the opattr into attributes
> Until we make it server unique this id parameter can only be leveraged 
> inside a partition, it cannot be used externally until we devise some 
> of these schemes discussed in [0] regarding 8 to 16-bit embedded 
> partition identifiers inside this Long.
Even if we dedicate some few bits to the partition 'name', with a long, 
we can still deal with much more potential entries than we can possibly 
store on a disk, considering that an entry will be at least 100 bytes long !

For instance, if we split the ID in two 16 bits values, this still leave 
4 billions entries that can be added, around 400 Gb of data...

A partition can be set on 8 bits - so we can handle as many as 255 
partitions, considering that partition 0 is ou=system -, more than 
necessary, I think. This leave more than 18 peta entries which can be 
stored... I would dedicate 16 bits to describe the partition (65 555 
possible partitions, 2^48 entries)

This has to be discussed...
> Any thoughts on exposing this ID and associating it with a ServerEntry 
> via an 'id' property on this class now rather than waiting for [0] to 
> be implemented?
> ---------
> [0] - 

cordialement, regards,
Emmanuel L├ęcharny

View raw message