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

Re: ldbm writesync

At 05:49 AM 12/2/99 -0800, Howard Chu wrote:
>Just a suggestion, on the topic of cache flushing and such... In the
>interest of speeding up bulk write operations:
>	perform ldbm_open without writesync
>	keep track of a "dirty" flag
>	on *read* operations check for dirty, and perform an explicit
>	    ldbm_sync.
>The ldbm_sync can be invoked after the read results are sent back to the
>client, to avoid making the reader wait around. In the worst case of a very
>active directory with lots of writes & reads, this should be no worse than
>before. In the case of a major series of updates, this should be a bit
>faster. For the paranoid, you can always issue a search after a write to
>force a flush. Comments? (Other than "you've stayed awake too late again,

I prefer not to complicate the back-ldbm with such optimimizations.
Such bandaids will likely make back-ldbm less reliable.  Those who
want (today) speed (at the cost of data security) can disable the
write sync [on the master, but deploy a (private) slave with write
sync on].

I prefer we resolve the reliability and performance issues by
designing and implementing a backend which takes advantage of
database transactions offerred by some database managers (such
as Sleepycat Berkeley DB).

I am hope that we can gather enough development support to make
back-bdb2 (or back-sleepy) a reality.


Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>