back-bdb nested transactions

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

I'm still occasionally running into assert failures in the cache code during
the modrdn operations in test008. I believe this is caused by operations that
touch the cache state outside of a lock; since the BDB locks are freed at
TXN_COMMIT time any last-minute bookkeeping that happens is unprotected.

My quick fix for this is to nest the transactions that are going on; so all
the database updates occur in a nested transaction, which is committed by
itself, and then the cache commits are done, and finally the parent
transaction commits.

I'm also in the midst of testing the new hierarchical cache code, which will
also rely on nested transactions. Since the cache code is now
transaction-protected, the internal "state" is no longer necessary - only
valid info is ever in the cache, and the locks prevent accessing the cache in
intermediate states.

Along the way, I did some tests to see if using a child transaction for the
individual database updates would help with deadlock recovery. It seems not
to; when deadlock occurs it is very rare that just aborting the child
transaction will allow things to proceed. I tried setting 3 retries on the
child transaction before aborting the whole thing; this wins very very
rarely. Without the limit on child retries it would just hang, retrying
forever...

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