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

Re: back-bdb IDL limitations


From experiments, I didn't see a significant reduction in the population time by the removal of the transactions. The experimental data shows instead that it is the number of database operations which has more effect on the performance of the 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


Howard Chu <hyc@symas.com>
Sent by: owner-openldap-devel@OpenLDAP.org

03/04/2005 11:56 AM

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



David Boreham wrote:

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

Agreed. The '-q' quick flag for slapadd in 2.3 turns off transactions
and locking. It makes things quite a bit more tolerable for large bulk
loads...

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support

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