There's a race between closing the storage and shutting down the
ConnectThread.  If we return here, the ConnectThread does no harm.

FileStorage.  Fixed this and then had to no-op all the tests that
MappingStorage can't possibly pass.

I think there may still be problems with BDB which I'll follow up on
next.

You never need an __del__ to close a file.  A file closes itself when
it is deallocated.

Don't give an object a magic __del__ attribute.  It won't work with
new-style classes, and it's obscure anyway.

The DB's invalidate() method takes a set of oids corresponding to all
the changes from a data manager for one transaction.  All the objects
are invalidated at once.

Add a few tests in testZODB of the new code.  The tests just cover
corner cases, because I can't think of a sensible way to test the
atomicity.  When it has failed in the past, it's been caused by
nearly-impossible to reproduce data races.

This fix needs to be backported to Zope 2.6, but only after assessing
how significant an impact the API change will have.

bytesread accumulator, not the chunklen which is the number of bytes
we wanted to read.

XXX Not sure where this macro is used or what kind of failures this
bug caused.

I've fixed the various scripts etc. in the CVS so that I can now install a ZEO client/server setup. The way it actually ended up working is:

- runzope.py and zopectl.py are moved to Zope/Startup/run.py and Zope/zdaemon/zopectl.py respectively
- bin/mkzopeinstance now takes a "-z/--zeo host:port" which sets up a custom_zodb.py in the new zope instance home
- bin/mkzeoinstance now overrides less, because...
- ZEO/mkzeoinst.py generates an additional script, runzeo, which is the "runner" for the ZEO server. Both it an the zeoctl script need to know about the ZOPE_HOME, so that's been added to the scripts (via the params)
- fixed setup.py so it installed ZEO/schema.xml

 - the scripts won't be in the user's $PATH, so override that lookup
   in from mkzeoinst.py in the mkzeoinstance script
 - the scripts won't be executable, so prepend commands with $python

The implementation is to make the reference in the cache "ring" a new
reference rather than a borrowed reference.  It is the intent of the
cache to keep N recently used objects in memory, regardless of whether
they are currently referenced.  The goal is to avoid the cost of
recreating the objects, based on the assumption that they are likely
to be used again soon.

The cache behaves differently now; it doesn't keep objects alive
artificially.  We should write some new tests that verify behavior
with objects that are kept alive by external references.

details.

The cache is intended to keep weak references to objects.  An object
should be deallocated when the only references to it are in the
cache.  If an object is unghostified and added to the list of live
objects, the list should have a borrowed reference.  Otherwise, the
cache will keep the object alive after all other references have
disappeared.

time.  Instead use std PyDict_GetItem() and incref only when
necessary.

The cache decrefed it in percachedel.

PyDict_DelItem() will undo the other INCREF.

Decref its reference to the cache.
In a debug build, account for the two bogus additions to _Py_RefTotal.

Also, reindent initcPickleCache().

Remove object_from_oid() which appeared to be mis-used about half the
time.  Instead use std PyDict_GetItem() and incref only when
necessary.

Make sure an object's reference to its cache is decref'd when the
object is deallocated.  This change seems to eliminate leaking pickle
caches.

Remaining mystery: Why do objects stay in the cache even when there
are no references to them?

release.

descriptions.

and are of questionable value.  "constructor" is also generally unsafe;
applications that need it can provide their own version of this if necessary.

- simplify document structure at one point

- fixed datatype of the values for "handler" attributes
- removed/commented out all mentions of schema component extension;
  that's really not complete and should probably be thought through
  again
- moved docs for legacy API out; these should not be generally
  documented
- misc. small fixes

The manager should raise an exception in its prepare() method rather
than returning a boolean to indicate failure.  Rationale: The txn
manager can't raise a reasonable exception, because it doesn't know
what the data manager couldn't prepare.