RE: BDB entry cache submission

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Marijn Meijles

> I looked at the cvs and this will be deadlock galore for reasons
> I've outlined some time ago. Have fun hunting ;)

I'm quite certain that this code will undergo a great deal of revision.
All I said was that it works under a particular set of known circumstances...

Meanwhile, now that we're all back from Christmas break and recovered from
all the New Years resolutions, how goes your super-duper new backend design?

I gave some thought to your complaint about back-hdb cheating by reading the
entire tree into RAM. I was almost motivated enough to rewrite it into a more
traditional tree structure (nodes point to children instead of nodes point to
parent). This would allow navigating the DIT without being forced to read it
all in at once. It could allow servers with relatively small amounts of memory
to handle inordinately large databases. But ultimately, there's not much to be
gained here. If your database is too big relative to your working RAM, the
overhead of the internal Btree pages will still prevent your small server from
effectively servicing requests. Rather than continually incur the overhead of
traversing both the dn2id Btree pages and the id2entry pages, it's still more
efficient to traverse the entire dn2parent database a single time and then
manage that independently, so that the BDB library really just has to deal with
the id2entry traversals.

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