trouble here on Windows, due to the poor granulatiry of Windows time.time()
feeding into pack-time selection in this test.  Moved the snooze() from
before pack time selection to after it, which appears to be a sufficient
fix; this can't hurt Linux, because the snooze() calls aren't needed at
all there (but don't hurt either).

for a redundant pack.

"Yow!" here anymore <wink>.

Also remove some unused imports and a somewhat irrelevant comment.

I don't really understand why this change and the last one to
runzeo.py have their apparent effects, but the tests work and the -m
option to runzeo.py works.

Noted by Jon Dyte.

Bug fix from Jon Dyte.

The comment long ago fell out of synch with the code.

The Connection class inherits from the ExportImport mixin, but they
had an arm's length interaction.  Restructure the code to provide
direct interaction via the _import attribute.

Remove the more general onCommitCallback() method.  It was only used
by ExportImport.

A lot of cosmetic changes to ExportImport:
    - don't make local variables out of attribute lookups
    - avoid local variable names that shadow builtins
    - prefer isinstance() to type comparisons
    - prefer absolute imports to relative imports

The server was sending all the invalidations from the queue, not just
the ones that were later than the requested tid.  This didn't affect
correctness of the cache, but did cause it to throw out valid data.

Add test case to verify that getInvalidations() returns only what is
expected.

Bug fix candidate.

ways, but unittest never notices this because the tests always fail in
a thread unittest doesn't know anything about.  Changed ClientThread
to derive from the MTStorage tests' TestThread, which arranges to re-raise
a thread-death exception in the main thread.  Tested "by hand", via
temporarily forcing fatal thread exceptions in all the Pack[Now]WhileWriting
tests; unittest did notice those now.  So, when this happens again in real
life, we'll no longer be fooled by test runner reports claiming that
everything passed, and then frustrated by not even being able to tell
which test failed (you can't tell from the isolated thread traceback(s)
wading in the sea of testrunner dot output).

available

in a new tuple.  If the chain of stuff triggered by the
subsequent PyEval_CallObject() happened to trigger cyclic gc, then there
were more gc-visible pointers to self than could be accounted for by
self->ob_refcnt, and in a debug build Python died with an assertion
failure.

The code has always been this way, but Jeremy points out that it didn't
matter in previous versions of ZODB, because "self" was always an
ExtensionClass instance before, and gc ignored those.

ZRS compatibility.

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.