Non-ghostifiable (persistent classes) objects load their state right
  away -- even before they are placed in the cache.  This causes a
  problem if the object's state has a (direct or indirect) reference to
  it. Added a pre-cache that allows the connection to return objects
  already being loaded when necessary.

apply the garbage collections on those connections in the pool that are
closed. (This fixed issue 113932.)

can cause signidficant delays, especially on systems with very
course-grained sleeps, like most linux systems.

Extracted from rev 73871 in svn://svn.zope.org/repos/main/ZODB/trunk/src/ZEO
(Jim Fulton did the extracting and handed me the diff on IRC).

  "add new 64-bit btree types (patch from Jim), merged from trunk"

Even though, as noted in the history file, there is no official release
of standalone ZODB 3.7, it corresponds with the release of Zope 3.3 and
2.10 in 2006, and should be considered feature-frozen.  Jim has
requested that these changes be reserved for the trunk (to be ZODB 3.8).

A subsequent checkin will clarify the status of 3.7 in HISTORY.txt.

problem reported on zodb-dev:

http://mail.zope.org/pipermail/zodb-dev/2006-August/010343.html

Added a new invalidateCache protocol for DBs and Connections to
invalidate the entire in-memory caches.  This is used when ZEO clients
reconnect.

problem reported on zodb-dev:

http://mail.zope.org/pipermail/zodb-dev/2006-August/010343.html

Added a new invalidateCache protocol for DBs and Connections to
invalidate the entire in-memory caches.  This is used when ZEO clients
reconnect.

port that nothing's listening on.

As per Tim's commit at http://svn.zope.org/ZODB/trunk/README.txt?rev=39824&r1=38707&r2=39824 , we now require Python 2.4.2.

test for it.

explicitly flush output to make sure we see test results.

ClientStorage could be in either "sync" mode or "async" mode.  Now
there is just "async" mode.  There is now a dedicicated asyncore main
loop dedicated to ZEO clients.

This addresses a test failure on Mac OS X,
http://www.zope.org/Collectors/Zope3-dev/650, that I believe was due
to a bug in sync mode. Some asyncore-based code was being called from
multiple threads that didn't expect to be.

Converting to always-async mode revealed some bugs that weren't caught
before because the tests ran in sync mode.  These problems could
explain some problems we've seen at times with clients taking a long
time to reconnect after a disconnect.

Added a partial heart beat to try to detect lost connections that
aren't otherwise caught,
http://mail.zope.org/pipermail/zodb-dev/2005-June/008951.html, by
perioidically writing to all connections during periods of inactivity.

o Most notably, ZEO.ClientStorage (http://www.zope.org/Collectors/Zope/2016).

o Forward-ported from 3.4 branch.

I'm not particularly proud of the tests I wrote.  It's way to hard to
write tests for ZEO.  Without a lot of white-box trickery, nothing can
be tested without making network connections, which is insane. ZEO's 
architecture needs to change.

I finally had to resort to os._exit, which I'm not happy about,
although I don't suppose it could do any harm for the test runner.

I wonder is a test is leaving something behind it shouldn't.

Also return the test result status as the exit status.

PersistentMapping was inadvertently pickling volatile attributes (http://www.zope.org/Collectors/Zope/2052).

See http://www.zope.org/Collectors/Zope/2027.

replaced `x` with repr(x), and replaced apply(x, y) with x(*y)

For multiple undo to succeed, the undo operations have to be
performed in a specific order.  The order was not being retained
by ZODB and was instead semi-random (the order depended on the
id() function.)  Now undo operations (as well as all
ResourceManagers) are sorted by creation order.