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>

Connection initialized _map as a dict containing a single entry
mapping the connection's fileno to the connection.  That was a misuse
of the _map variable, which is also used by the asyncore.dispatcher
base class to indicate whether the dispatcher users the default
socket_map or a custom socket_map.  A recent change to asyncore caused
it to use _map in its add_channel() and del_channel() methods, which
presumes to be a bug fix (may get ported to 2.3).  That causes our
dubious use of _map to be a problem, because we also put the
Connections in the global socket_map.  The new asyncore won't remove
it from the global socket map, because it has a custom _map.

Also change a bunch of 0/1s to False/Trues.