created the possibility that the checking code would need to try to read
up data from a closed connection.  This turned out to be a frequent source
of new failures in checkConcurrentUpdates1Storage (both FileStorage and BDB
flavors).  Changed all of the relevant tests to grab the BTree anew from
the newly-opened connection.

missing keys.

Don't use bpthread; just use thread.

In the branches that call loadBefore() or raise ConflictError, make
sure we always return.  Either case satisfies the original call to
setstate() and we don't want to load the current state.

ZConfig.components.logger, adding only what's special about the zLOG
version of the factory

Bug reported by Dieter Maurer.

The change required several of the read-conflict tests to be updated
to specify that they don't want MVCC support.  It was basically
accidental that they passed before this change.  Note that we don't
have any tests of code that gets a read conflict in MVCC mode, which
would only be possible after a pack() or in some other weird case.

problem is likely somewhere else, but I'm not going to stay up tonight
sorting this out.

docstring, this function never returned True.

- time-interval values are the number of seconds

BTrees.check module and to the BTree._check() method.

ZConfig.logger.log type, since it does

the logging package; this avoids lots of code duplication

This old script was provided in 3.2 only to ease transition.  Removed
now, because it depends on zdaemon.Daemon, which no longer exists.

The last tid is already set as a result of the invalidate() calls made
in _update_cache().

previous one" check fails.  Surprise!  The test was using tid < self.tid,
not <=, so it can't be the case that the test was failing because the new
tid was equal to the last one.  Changed the test to use <=.  Maybe that's
not a good change, but, if not, then the error message is wrong <wink>.

<import>