RE: back-bdb2 in progress

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:34 AM 3/15/00 -0800, Howard Chu wrote:
>My quick fix for slow add times, which Kurt wasn't too keen on:

For numerous reasons...  first being that it doesn't solve the
problem and two there are reasonable workarounds to build robust
configurations (using slaves).  If you want a single server solution,
then you should not defer the sync the disk.

>I delay all write-syncs, maintaining a "dirty" flag for each cache.
>Then on any read operation, cache is flushed if "dirty" is true.

Not needed.  The underlying databases maintains "dirty" bits.
We just need to call ldbm_cache_flush_all().

>This allows
>bulk loading of data to occur pretty quickly, and all you need to do is
>issue a search command to perform a sync as desired.

We should require modification of clients to do server-side
syncing.  syncing should be based solely on update operations.

>(Kurt said the right
>solution is to get back-bdb2 up to snuff. Yes, true, but my approach
>provides immediate relief for a pretty common complaint.)

One possible alternative is to disable the per ldbm write sync
and do a ldbm_cache_flush_all() after each ldap update operation.  

Another alternative is to use a timer approach.

>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>
>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Andrew Davison
>> Sent: Tuesday, March 14, 2000 7:48 PM
>> To: openldap-devel
>> Subject: back-bdb2 in progress
>>
>>
>> Is anything happening with BACK-BDB2? I haven't seen any mention
>> of it for a
>> while. The last thing I saw was something about abandoning it and
>> restarting, which doesn't bode well as it's supposed to be the panacea to
>> slow add times without setting 'dbcacheNoWsync'.
>>
>>
>
>