[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,
>Howard...")
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
----
Kurt D. Zeilenga <kurt@boolean.net>
Net Boolean Incorporated <http://www.boolean.net/>