The Berkeley DB 4.4 release introduces a number of important new features
in three major functional areas.
The first area is in limiting when database environment recovery needs
to be performed. The Berkeley DB 4.4 release introduces the ability
to abort transactions and release locks held by processes that have
failed, without exiting the database environment and performing
recovery. In addition, the 4.4 release also introduces the ability to
serialize the database environment creation process, performing
recovery automatically as necessary. This feature can significantly
simplify the architecture of applications comprised of multiple
concurrent processes.

Since BDB now does auto-recover, is alock going to cause conflicts?

The second area is database compaction. The Berkeley DB 4.4 release
introduces the ability to compact databases, optionally returning
space to the underlying filesystem. Database compaction does not
require the database be quiescent, and can be performed concurrently
with other database access.

I think database compaction sounds amazingly useful, especially if someone
performs many deletes. There has already been one issue raised on the
-software list of a user who did a large scale delete, and had performance
plummet. Since this can be performed concurrently, perhaps an option in
slapd to schedule compaction? (I'd probably run mine monthly or something.
:P ).