RE: back-bdb future

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

At 06:07 AM 3/16/2003, Howard Chu wrote:
>> -----Original Message-----
>> From: Jonghyuk Choi [mailto:jongchoi@us.ibm.com]
>
>> >At one point Kurt mentioned exploring using BDB itself for the cache,
>> using a
>> >memory-only database. Has anyone looked into this? I wonder what the
>> >semantics are for such a database in a transaction
>> environment, since it
>> has
>> >no persistent store.
>>
>> BDB cache's gain over database page cache may not be large.
>> In addition to the normal DB access overhead, transaction
>> subsystem adds
>> 3~7% of excess overhead even for non-transaction protected searches.
>> so... entry cache would still be considered as a higher perf store.
>> - Jong
>
>My wording may not have been too clear. I am not talking about using a
>memory-only BDB database to store entries in a disk-datbase-style format. I
>mean using the memory-only database to store the pointers to the cached
>entries, instead of using libavl. The question is whether a hashing scheme,
>or a Btree scheme, might be more efficient than an AVL tree.

On nice thing about using BDB here is that they provide a
common API for both Btree and Hash structures.

>However, your point about DB overhead probably still stands.

In back-bdb, that overhead will likely have to be increased due
to read transactions.   The only way I can see to resolve the
read deadlock problems otherwise would be to ensure backend
is never reading and writing at the same time.