instead of any other error that may be raised.

After consultation with Jim, we agreed that Full's behavior vis object
serial numbers after a version commit/abort are correct.  The new
revision should get the serial number of the transaction that did the
commit/abort.

FileStorage is actually broken here; the new revision gets the same
serial number as the last in-version revision.  However, the way the
tests are written, it works for either storage, so I'm just updating
some comments to explain the situation.

Note: Jim also explained that history()'s "version" argument should be
ignored.  Doesn't make much difference to these tests though.

storage API.

including self) to be called `size' not `length'.  This should be
considered part of the contract of this method, so the keyword
argument name has been changed.

subclass Transaction.

made keys() method return a *copy* of the cached keys list, preventing mutations of the cached keys list that could cause later problems.  (Collector 2283).

(Collector #2277)

If an exception is raised, make sure the current transaction is
aborted.  And catch more of the oddball exceptions that can get raised
when a server disconnects -- like thread.error.

Note that requirement of Zope 2.2 or higher.  Explain how to put
cPickle in the right place in your Zope tree.

Add checkReconnection() to renamed ConnectionTests (was
PersistentCacheTests).

Close the client storage explicitly in the tear down to avoid spurious
warnings from threads attempting to connect after the test is over.

closeIntensionally() is called when the storage's close() method is
called.  close() is called when the other end reset the connection.
The __closed should only be set with the asyncRPC object should never
re-open the connection.

Reported by Dyon Balding.

partially committed.  If an object is stored more than once in a
version during a single transaction (which is borderline behavior anyway)
and that object has been modified for the first time in the version,
the old logic would stop prematurely.

Many methods had default arguments that were used to bind a global or
builtin name, like type, None, or type(''), as a local name.  In many
cases, the names bound were not referenced in the method body
(presumably they used to be referenced).

commit_sub(): In this one case, delete the default arg anyway, because
    it's only used once.

The same effect can be achieved by:
db.begin_invalidation()
for oid in oids_to_invalidate:
    db.invalidate(oid)
db.finish_invalidation()

There are two kinds of callbacks, commit actions and close actions.
It is assumed that the use of these callbacks is infrequent.  As a
result, the implementation used tuples defined as class attributes to
avoid creation of instance variables to hold callbacks in the common
case.  This implementation is complicated because tuples are
immutable.  Unfortunately, the instance variables were actually
created anyway in tpc_abort() and tpc_vote().

This implementation changes the class attributes __onCloseCallbacks
and __onCommitCallbacks to default to None.  If a callback is
registered with an instance, a list is bound to an instance attribute
of the same name.  When the transaction commits or aborts, the
instance attribute is deleted.

tpc_vote(): Remove the default arguments since they are unused in the
body of the method.

__init__(): __closed = 0
connect(): In connecting thread, don't continue if __closed is true.
close(): __closed = 1

If one thread was committing a transaction and another thread was
opening a new DB connection, deadlock could occur.  The cause of the
deadlock is that tpc_finish() acquires the storage and db locks in a
different order than DB.open().  As a result, if each starts at the
same time and gets one of the two locks it needs, the system will be
deadlocked.

The solution is to enforce a consistent locking order.  If a thread is
going to hold the DB lock and the storage lock, it MUST acquire the DB
lock first.  This patch implements that locking order for the
invalidation in tpc_finish().

The DB object gets methods called begin_invalidation() and
finish_invalidation() that acquire and release the DB lock
respectively.  Before the Connection calls tpc_finish() on the
storage, it calls begin_invalidation().  This guarantees that the DB
acquired before the storage lock.

When the invalidation phase is over, the Connection calls
end_invalidation() to release the DB lock.  This is an optimization.
It could wait until tpc_finish() returns, but we know that the DB will
not be used again for the rest of the tpc_finish() and tpc_finish()
could take a long time.

Specific changes:

DB.py
begin_invalidation(): Added.
finish_invalidation(): Added.
invalidate(): Remove locking.
invalidateMany(): Add comment about how it should be used.

Connection.py
tpc_finish(): Don't pass second argument to storage's tpc_finish()
    when committing a transaction with no data.  Add call to
    begin_invalidation() before calling storage's tpc_finish().
_invalidate_sub(): Remove empty, unnecessary method.
_invalidating_invalidating(): Add call to finish_invalidation() after
    last call to DB's invalidate().

Eventually, we should add registration for the other flavors too.
This will require deciding how to specify the II, IO, OI variants. ;)

Fixed a type that prevented import.
Changed interface registration to take advantage of the fact
that we have classes.

Fix bug reported by John D. Heintz.

"supportsTransactionalUndo()" method.

XXX untested

XXX This mechanism for feature evolutional doesn't seem right, because
it because a morass of backwards compatibility issues.  I'd rather see
the test by one of presence/absence of an attribute or a base class.