The order in which the tpc_finish() method of the jars is called is
dependent on the order in which objects are returned from
dict.values().  There is no way to write a test that works on all
platforms that produces a consistent result in dict.values(), so stop
trying.

Instead, have the jars explicitly coordinate their tpc_finish()
methods so that the first call always succeeds and the second call
always fails.

The main idea in the bug fix is to recover more gracefully when
something goes wrong trying to load classes for conflict resolution.

XXX This accidentally got checked in on the Zope 2.5 branch first.

Not sure about this judgement call.  It is really convenient to be
able to pack a ZEO server, even if it is only accepting read-only
connections.  Is pack() a write operation?  At one level: Yes, it
modifies the data.fs.  But it doesn't modify current objects, so it
isn't the same as calling store().

We can revisit this later if it ends up being a problem for someone.

After setting self._transaction, release the lock.  Then reacquire it
before the notify().  The wait() call is sufficient to block the other
threads; holding the lock is not necessary.

As a result, it doesn't matter if the same thread calls tpc_begin()
and tpc_abort() for a given transaction.  So remove assertion.

and remove testExceptionInTpcFinish() and BUGtestExceptionInSubTpcBegin().

The tpc_finish test removed duplicated the logic of "hoser stoppage,"
while the BUGtest was never executed.

The testHoserStoppage() test used to depend on the order of objects in
a dict's values() list.  This order was unpredictable and caused
intermittent failures.  Make two changes to work around this:  1) Mark
the non-error object as modified first, since this seems to get
values() in a good order.  2) Retry the test with 2 randomly selected
objects until it passes, but fail after 10 tries.

The HoserStoppage and ExceptionInTpcFinish were failing intermittently
on Windows.  I assume the problem is that a single error in tpc_finish()
can be recovered from iff the error is for the first jar.  I assume that
most of the time the error occurred after some other jar had committed.
Fixed the test by causing two different jars to fail.

XXX This makes CommitLockTests pass on Win2k for me.

tpc_abort() and tpc_finish() should always reset _transaction and
strategy attributes before calling _handle_waiting().  XXX Not sure
that it actually makes a difference, but the code seems simpler.

Only issues the "blocked transaction restarted" method when _restart()
returns true.

XXX If select() raises an exception inside asyncore, close the connection.

Use TestThread as base class for WorkerThread in CommitLockTests.

StorageTestBase.removefs() will attempt to remove files with all the
possible extensions that FileStorage will create.  It will raise
os.error for any error except ENOENT.

Remove many variants of removefs() implemented in the various test
suites.

Add a poll call in send_reply() so that synchronous calls made when
there is no other traffic don't cause long delays.  (This probably
only occurs during the pack tests.)

XXX This will probably hang for Guido.

Mark each WorkerThread as a daemon.  Attempt to join() it when the
test exits, but do so with a timeout.  If, after the join(), the
thread is still alive, mark the test as failed.  Since it's just a
daemon thread, the test program should still exit.

Also, reformat doc strings, remove an unused global variable, and
remove one whitespace character.  (I've already used the whitespace
in a different module.)

No log writer that I know of has a reinitialize() function.
zLOG has an initialize() function, but it isn't easy to get at yet.