directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ersin Er <ersin...@gmail.com>
Subject Optimizing DB access with improving key usage
Date Thu, 20 Jul 2006 14:46:18 GMT
[RESENDING]

Hi all,

The optimization branch is busy with extensive refactorings and things
are going well. We had a few convos recently for further improving the
performance and one of the points of improvement was thought as
replacing the BigInteger construct which we use as the key of Attributes
objects in the database.

What we do when retrieving and Attributes object is first retrieving a
BigInteger stored in the db for the normalized DN and then doing one
more lookup for the actual Attributes object using the BigInteger as the
key.

The first improvement to be done is to replace BigInteger with int or
long which cost much less. But as Alex just (yes, at the time of writing
this :) ) warned me about that jdbm keys should be objects not
primitives. So my second suggestion is again replacing the BigInteger
with more leightweight class like Integer and generating that Integer
for each LdapDN at the time of construction. I think we do not need to
do one more lookup to retrieve the (Big)Integer key of the Attributes
object. We can just generate a hash value at LdapDN constructor and
provide a method for accessing it when we want to store or retrieve
Attributes objects. Of course, the hash code should be generated from
normalized components of the DN. As a DN is a primary key for an LDAP
tree, again a unique key generated from it will serve as the primary key
for the whole backend DB.

WDYT ?

-- 
Ersin


Mime
View raw message