back-bdb future

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

For 2.2, we should probably consider using lists of IDL ranges. Could get
ugly, but it might be more useful for large databases.

I'm also looking into revamping entry caching to make it hierarchical, like
back-hdb. Currently there's a bit of duplication of effort between back-hdb's
data structures and the entry cache.

Each cache node will store the node's rdn and an AVL tree of its immediate
children. The number of AVL search steps may ultimately be greater, but it
will allow finer grained locking on the cache, so overall concurrency should
improve. (It remains to be seen whether this change will be the default case
or only for back-hdb. Or whether back-hdb should replace back-bdb. Ultimately
I believe it will prove to be the better choice, but not yet.)

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.

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