This triggered some code changes.  When closing a connection,
the meaning of "the pool is too big" is debatable:  it may mean
that the number of all connections the pool knows about exceeds
pool_size, or it may mean that the stack of available
connections (a subset of all the connections) exceeds pool_size.

The code was changed to mean the latter, primarily because it's
predictable.  The total number of connections the pool knows
about can change at any time, because it depends on which weak
references DB holds that cyclic gc hasn't yet cleared.

But it doesn't matter much either way, since clients are never
"supposed to" exceed pool_size anyway.  I think it degrades
more gracefully this way.

Also test that DB's internal weakrefs don't keep a
Connection alive on their own.

This can happen during DB construction, or after the fact.

zope.testing instead of rolling our own.

Changed the behavior of _ConnectionPool.pop(), to return
None when no connections are available.

Document _p_invalidate().

Most relevant code is much simpler now; there's no longer
a hard limit on the # of connections per DB.  All the
tests pass, but test coverage of the sprawling DB API isn't
very good.

Also gave WeakSet a suitable __contains__ implementation.

If nothing else, it highlights that the transaction package
got put in a wrong place (it and ZODB depend on each other).

Start simplifying the code.

Code cleanups.

Imports normalization.

Now use ZODB.utils.z64 instead of '\0\0\0\0\0\0\0\0' where appropriate.

Connection.root():  Repair error in docstring.

Remove duplicate declaration and definition of py___getstate__.

The tests here have to be run manually for now, so rename
the directory so test.py doesn't complain about it.

Duplicate import removed.

Merge revs 27788 and 27795 from Zope trunk.

See Collector #1350.

ghostify() and unghostify() detect one form of thread insanity
now.  In a debug build, they abort the process if it happens.
In a release build, unghostify() raises SystemError, and
ghostify() ignores it (ghostify() can't raise an exception).

See Collector #1350.

ghostify() and unghostify() detect one form of thread insanity
now.  In a debug build, they abort the process if it happens.
In a release build, unghostify() raises SystemError, and
ghostify() ignores it (ghostify() can't raise an exception).

before I went on vacation a couple weeks ago.