Fred's machine, due to this routine falling off the end and returning
None.  Sync'ing the connection after a ConflictError appears to fix
it, or at least make it much less likely to fail.

not enough stuff in the Windows Python to wait for spawned servers to shut
down.  Spawned servers inherit descriptors for open files from the
spawning process, and because Windows won't let you delete a file that's
still open, the client can't get rid of temp .zec files until the server(s)
disappear(s).  There's no good fix for this before 2.3 on Windows.  For
now, try deleting the temp files repeatedly, sleeping between failures,
but don't wait forever.  If a temp file can't be deleted in the end, raise
the appropriate exception.  This should be rare.  It's important not to
keep going blindly, as I saw one case earlier today where a test passed
by accident due to picking up a .zec file left behind by a previous test
run.

it actually manages to do a commit on the second server.

too.  Mystery:  whether this test dies with permission denied when
trying to unlink the .zec file is still a crapshoot.   Don't know why.
At least four other tests show sporadic failures of the same kind.

Otherwise the temp zec file can't be deleted on Windows.

zec file name (the code intended to do this all along).

It was lost backporting changes from the 3.1 branch, which doesn't
have the last tid feature.

(All the other non-test ZODB code uses cStringIO.)

it up to date.

they shouldn't run with mapping storage.

parallel with message about acquiring the lock.

Ported from ZODB3-3_1-branch.

The ZEO client cache now works with OIDs of length up to 65535 bytes.
Also added some sanity checks that check the size of the data being written,
since there are some hard limits.

ZODB now makes no assumptions about the length of OIDs (although
storages can make such assumptions if they need to.)  Added an
oid_repr utility function to print both 8-byte OIDs and other OIDs in
a reasonable way.

ones.