identification harder, especially when generic test classes are
inherited by multiple specific test classes.)

- Document the correct persistent filenames and the presence of a
  magic number at the start of the file.  (Also document the
  conditions under which the cache is persistent.)

- In __init__(), seek to the correct position to read the first
  record's serialno.  It was reading the last byte of dlen plus the
  first 7 bytes of the serialno.

- In invalidate(), fix the seek call after the read(8) to actually
  seek to the status byte.  It was seeking 8 bytes too far, causing it
  to overwrite the 2nd byte of dlen instead of the status byte.

This will cause three failures with the current version of
ClientCache.py, because some of the tests were specifically written to
verify certain bugs.  I will check in fixes for thse bugs shortly.

Use STUPID_LOG_FILE instead of EVENT_LOG_FILE so that it works with
older Zopes.

Make sure buf1 is defined even if open() never succeeds.

The one in ZEO/trigger.py was the good code, but we want it to live in
ZEO/zrpc/trigger.py.  This checkin makes that change.

The key checkin of ZEO/trigger.py had this checkin comment:
Fix trigger close/__del__.

The close() mechanism for an asyncore file_dispatcher is not safe to
call multiple times.  It's calling os.close() on a file descriptor
(int).  Guido observed that if you call close() twice, you could be in
trouble:  1) First close() call closes FD 6.  2) Another bit of code
opens a new file, getting FD 6.  3) Second close() call closes FD 6.
Waah!  FD 6 is some other file.

The workaround attempt here is to define a close() method on a trigger
that only closes the file descriptors the first time.

Also, make sure that both file descriptors are closed.  The previous
version only closed the read-end of the pipe.

Boost the accumulator limit to 60000.
Use "".join() to accumulate multiple strings, since it is not unusual
to have more than 2 strings to join together.

Add comment explaining why we do this stuff.

StorageTransactionError.  This exception is raised when a transaction
exhausts some finite storage resource.  E.g. a transaction changing a
huge number of objects could fill a Berkeley lock table.

Also, removed some unnecessary `pass' statements, and improved
consistency in class docstrings (first line is a complete sentence).

Use this method to set self._transaction to None and notify another
thread.

Not only can we move the assignment of self._transaction about the
timestamp / id initialization, but we can eliminate the test for
self._server being None.  It will never be None.

self._server is the first instance variable initialized by
__init__().  It is also assigned to in notifyConnected() and
notifyDisconnected(), which do not assign it to None.

_basic_init():  repair tpc_cond comments in light of recent changes.
tpc_begin:  when self._server is None, do tpc_cond.notify() to let
other threads waiting for "_transaction is None" to continue.

anymore.  Tried to fix that.  Jeremy, please review the new XXX comments.

depending on whether the full or a partial test suite was run.  In
particular, in my case there was a EVENT_LOG_FILE turd left in the
environment which was causes StupidLogTest's checkBasics to fail.

The fix is to wipe the environment in both the setup and the tear
down, although I wonder why EventLogTest's teardown didn't clean
things up properly.  Hmm, with this patch the test suite succeeds.

use that everywhere internally instead of setting the global _log_dest
directly.

constructor.  It should use the start file, not the sys.executable.

testLogRestart(): Fix a race condition; the child process may not have
gotten around to creating the log file by the time the parent tried to
open it.  Use a dumb for/sleep loop.

directory, so it should be joined to self.var, not the local variable
`v'.

clause.

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.