back-bdb multiple access

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

Just some random, unsubstantiated notions - it occurs to me that the current
back-bdb (in HEAD) is probably fairly safe wrt multiple processes accessing a
single database. In particular, one should be able to use slapadd to create
new entries while slapd is running, without causing any harm. Currently the
index databases are not cached, so slapd will always be operating from a
consistent index. New entries won't exist in slapd's entry cache, but they
will be found if searched for.

The main issue that will not work is with multiple slapd's accessing a single
database; the use of entry caching means that if one slapd modifies an entry
that the other slapd has already cached, the other slapd will not see the
change. Also, the current startup code always initiates a DB_RECOVERY and
multiple instances of recovery on a single database will corrupt it. (This
was also happening when the tools init'd but that has been patched in HEAD.)

I suppose, if one really wanted to run multiple slapd's from a single BDB
database, one could comment out the DB_RECOVERY at startup, and set the
cachesize to 0, thus forcing each slapd to always use the database directly.
This would probably shoot any possible performance advantage from having
multiple servers though.

There's a question in my mind as to whether multiple servers accessing a
shared SCSI RAID or NAS could get any benefit out of this approach. The
shared filesystem needs to provide certain guarantees about cache consistency
already, but even more, for BDB's use, it has to support consistency for
mmap'd pages as well.

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