Re: back-bdb IDL limitations

[Jonghyuk Choi <jongchoi@us.ibm.com>]

The scheme that I proposed prioritizes
the performance of slapadd over that of ldapadd given it is common to use
slapadd when large number of entries are populated.
For ldapadd, IDs are added in a similar
way to the conventional indexing mechanism.

I didn't eliminate transactions for
the clustered slapadd because
1) there is already a recently added
mode, SLAP_TOOL_QUICK mode, for non-transaction protected slap tools operations,
and
2) there should be non-zero need for
transaction protected operations of slap tools to cope with a system failure
during a lengthy directory population.

- Jong-Hyuk

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979

"David Boreham" <david_list@boreham.org> Sent by: owner-openldap-devel@OpenLDAP.org 03/04/2005 10:45 AM

To:        <openldap-devel@OpenLDAP.org>         cc:                 Subject:        Re: back-bdb IDL limitations

A transaction begins and commits on
a cluster boundary as well. If something bad happens in the middle of slapadding,
the database will remain intact up to the previous cluster commit. I don't
see this as a limitation as long as the administrator is given the information
on the point his/her slapadd progressed to and as long as the cluster size
is not too large. 
I see. I missed the point that this was for slapadd. I
thought you
were descibing a mechanism that would be used for regular

LDAP operation processing (ADD, MOD...). I don't think
you
need transactions (nor locking) in slapadd.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature