"Blob temp file get's removed before it should",
https://bugs.launchpad.net/zodb/+bug/595378

A way this to happen is that a transaction is aborted after the
commit process has started. I don't know how this would happen in
the wild.

In 3.10.3, the ZEO tpc_abort call to the server is changed to be
synchronous, which should address this case. Maybe there's another
case.

----------

- "activity monitor not updated for subconnections when connection
  returned to pool"

https://bugs.launchpad.net/zodb/+bug/737198

difference.

Simplified and optimized marshalling code.

MRUish.

In some experiments, this led to significant reductions in cache miss
rates.

Fixed typo in comment

https://bugs.launchpad.net/zodb/+bug/677751

----------

- ZEO server transaction timeouts weren't logged as critical.

https://bugs.launchpad.net/zodb/+bug/670986

while running tests.

----------

- 3.10 introduced an optimization to try to address BTree conflict
  errors arrising for basing BTree keys on object ids. The
  optimization caused object ids allocated in aborted transactions to
  be reused. Unfortunately, this optimzation led to some rather
  severe failures in some applications.  The symptom is a conflict
  error in which one of the serials mentioned is zero.  This
  optimization has been removed.

  inherited from object, which compares based on in-process address.)
  Now BTrees warn if an attempt is made to save a key with
  comparison inherited from object. (This doesn't apply to old-style
  class instances.) This will become an error in ZODB 3.11.

- Unix domain sockets didn't work for ZEO (since the addition of IPv6
  support).

https://bugs.launchpad.net/zodb/+bug/663259

to be misshandled, causing incorrect statistics and errors.

  an external garbage collector with ZEO.  When objects were deleted
  from a storage, invalidations were sent to clients. This makes no
  sense.  It's wildly unlikely that the other connections/clients have
  copies of the garbage.  In normal storage garbage collection, we
  don't send invalidations. There's no reason to send them when an
  external garbage collector is used.

This is added insurance on
https://bugs.launchpad.net/zodb/+bug/665452.
In particular, because we saved dups, the damage persisted, requiring
a process restart to clear.

  When a transaction rolled back a savepoint after adding objects and
  subsequently added more objects and committed, an error could be
  raised "ValueError: A different object already has the same oid"
  causing the transaction to fail. Worse, this could leave a database
  in a state where subsequent transactions in the same process would
  fail.

https://bugs.launchpad.net/zodb/+bug/665452

- Moved 3.9 changes to HISTORY.txt.

- Consolidated 3.10 pre-release entries.

- Removed 3.10 (bug fix) entries for fixes that were in 3.9, so the
  3.10 changes are from 3.9.

- Changes to suppprt IPv6 broke a fix for a problem on Mac OS X that
  could cause a server to stop accepting connections.

----------

- When a pool timeout was specified for a database and old connections
  were removed due to timing out, an error occured due to a bug in the
  connection cleanup logic.

- When mulri-database connections were no longer used and cleaned up,
  their subconnections weren't cleaned up properly.

- On some systems, using an empty string in a server address of a ZEO
  client led to a socket error. Now, ZEO clients treat '' as an alias
  for 'localhost'.

- When using multi-databases, cache-management operations on a
  connection, cacheMinimize and cacheGC, weren't applied to
  subconnections.

of provoking the buildbot test failure that I hope I just fixed. :)