[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-bdb IDL limitations

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>
        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