correctly, leaving the client storage in an inconsistent state.

the file storage is closed because it's internal meta data may be
invalid.

number of writes.  This was done during the last phase of two-phase
commit, which made this critical phase more subject to errors than
it should have been.  Also, for large databases, saves were done so
infrequently as to be useless.  The feature was removed to reduce
the chance for errors during the last phase of two-phase commit.

initialized (as can happen when making a deep copy of a blob object)

than verifying it.

control.

triggers.  Now that server triggers are shared, it makes no sense to
close them.  It's possible that the old logic in _pull_trigger got
around the potential problem intriduced when I made the server trigger
shared. I can't think of a good reason, otherwise, why tests weren't
failing.

Getting rid of close trigger simplified the code a bit. Also factored
some common close behavior, allowing me to get rid of an override.

  with the data in a way that prevents data from being loaded into the
  cache. We don't yet know why, but added an exception handler to
  prevent this error from being fatal.

an out-of-date server.

servers that serve ZEO clients (use ZEO clients as their storages) to
be delayed.

  of a Python disctionary for a mapping that can grow large.

(Not large enough to use a lot of memory, but large enough to cause
  malloc to fail. :()

for objects that were explicitly added to a database if the object
was modified after a savepoint that added the object.

M      src/ZEO/tests/InvalidationTests.py
Fixed spurious scary intermittent test failure.

invalidation messages are recived after the cache is closed.

Changed connections to work with unset (None) clients.  Messages
aren't forwarded until the client is set.  This is to prevent sending
spurious invalidation messages until a client is ready to recieve them.

clients, but ZEO clients haven't provided very good protection,
leading to cache corruption.  We'll hopefully fix these client issues,
which cause other problems beside cache corruption, but it seems
prudent to provide low-level cache protection.

should close the old connection, and mark ourselves dissconnected --
or so it seems. :)  I'm chasing connection-invalidation bugs and this
rearrangement makes the logic seem a bit simpler to me and sets the
stage for a later fix for the invalidation problems.