directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ServerEntry] We may need our own JDBM code base
Date Thu, 07 Feb 2008 14:38:14 GMT
Hi Jörg,

first, I have to told you we didn't received any news from incubator for 
your code submission. I will try to ping incubator again to see if 
someting is stalling for a reason or if we have missed some step (I just 
suscribed to the incubator PMC today, I should have done it sooner, but 
I think I just forgot to do so and thought I already did it. My bad).

Back to the thread now :)

Jörg Henne wrote:
> Emmanuel Lecharny schrieb:
>> Any other solution in mind ?
> not having done any work on the backend makes it impossible for me to 
> make well-founded comments on the issue. However, the recent 
> discussion around splay trees and the problems with the current JDBM 
> layer got me thinking that the requirements of the database layer are 
> almost entirely identical to those of the RDBMS:
> - entries are reasonably similar to tuples
there is a big difference between entries (ldap) and data in a RDBMS : 
entries are multivalued. This make it more complex to manage such data 
efficiently in a database, but not impossible. In any case, this is 
> - all indexes are essentially secondary indexes
> - DNs are are similar to a primary key, but may also be treated like a 
> secondary one.
> Some not-so-lateral thinking brings up the question of whether it is 
> really necessary to invent another wheel. 
We don't want to reinvent the wheel, but to select the most appropriate 
kind of storage to get the most performance out of the server. When it 
comes to search, you have a three step approach which work :
- if you have less than a thousand elements, just use a list in memory
- under a few hundred of thousands elements, a hashmap is better, for 
non ordered data
- above one million, BTree will be better, just because you won't be 
able to cache everything.
> The idea may be totally silly, and the required effort may easily make 
> the think not worthwhile, but what about having a look at Derby's 
> store layer:
> and in particular
We have to check this. But switching from JDBM to Derby BTree might be 
way too costly  compared to the small modification I want to introduce 
into JDBM code base.

Let's say that what I want to do is to workaround a bigger problem until 
Alex has finished his cursors implementation. Then we will be able to 
think about decoupling ADS from JDBM and analyze some alternative like 
Derby BTree.

At some point, we really want Derby, Postgresql, LDIF, etc to be storage 
for ADS, like what OpenLdap supports :
bdb 	Berkeley DB transactional backend
config 	Slapd configuration backend
dnssrv 	DNS SRV backend
hdb 	Hierarchical variant of bdb backend
ldap 	Lightweight Directory Access Protocol (Proxy) backend
ldif 	Lightweight Data Interchange Format backend
meta 	Meta Directory backend
monitor 	Monitor backend
passwd 	Provides read-only access to /passwd/(5)
perl 	Perl Programmable backend
shell 	Shell (extern program) backend
sql 	SQL Programmable backend

Thanks for the heads up, Jörg !

cordialement, regards,
Emmanuel Lécharny

View raw message