[Zope-dev] ZODB3 3.1.1b2

[Barry A. Warsaw]

We've made another beta release of ZODB 3.1.1 available, including ZEO
2.0.2.  This is primarily a bug fix release; see the NEWS.txt file
excerpt below for details.  Of particular note are the enabling of the
BTrees-based index for FileStorage and the disabling of the rare
"hosed" state in ZODB.

This release corresponds to Zope 2.6.1b2 which was release on Friday
31-Jan-2003.  (The releases differ only in some inconsequential
Windows test modules.)

For more information, including links to download, please see:

    http://www.zope.org/Products/ZODB3.1

See also the ZODB wiki page for all things ZODB:

    http://www.zope.org/Wikis/ZODB

Enjoy,
-Barry & Jeremy

What's new in ZODB3 3.1.1 beta 2?
=================================
Release date: 03-Feb-2003

The Transaction "hosed" feature is disabled in this release.  If a
transaction fails during the tpc_finish() it is not possible, in
general, to know whether the storage is in a consistent state.  For
example, a ZEO server may commit the data and then fail before sending
confirmation of the commit to the client.  If multiple storages are
involved in a transaction, the problem is exacerbated: One storage may
commit the data while another fails to commit.  In previous versions
of ZODB, the database would set a global "hosed" flag that prevented
any other transaction from committing until an administrator could
check the status of the various failed storages and ensure that the
database is in a consistent state.  This approach favors data
consistency over availability.  The new approach is to log a panic but
continue.  In practice, availability seems to be more important than
consistency.  The failure mode is exceedingly rare in either case.

The BTrees-based fsIndex for FileStorage is enabled.  This version of
the index is faster to load and store via pickle and uses less memory
to store keys.  We had intended to enable this feature in an earlier
release, but failed to actually do it; thus, it's getting enabled as a
bug fix now.

Two rare bugs were fixed in BTrees conflict resolution.  The most
probable symptom of the bug would have been a segfault.  The bugs
were found via synthetic stress tests rather than bug reports.

A value-based consistency checker for BTrees was added.  See the
module BTrees.check for the checker and other utilities for working
with BTrees.

A new script called repozo.py was added.  This script, originally
written by Anthony Baxter, provides an incremental backup scheme for
FileStorage based storages.

zeopack.py has been fixed to use a read-only connection.

Various small autopack-related race conditions have been fixed in the
Berkeley storage implementations.  There have been some table changes
to the Berkeley storages so any storage you created in 3.1.1b1 may not
work.  Part of these changes was to add a storage version number to
the schema so these types of incompatible changes can be avoided in
the future.

Removed the chance of bogus warnings in the FileStorage iterator.

ZEO
---

The ZEO version number was bumped to 2.0.2 on account of the following
minor feature additions.

The performance of full cache verification has improved dramatically.
XXX Get measurements from Jim -- somewhere in 2x-5x recall.  The
implementation was fixed to use the very-fast getSerial() method on
the storage instead of the comparatively slow load().

The ZEO server has an optional timeout feature that will abort a
connection that does not commit within a certain amount of time.  The
timeout works by closing the socket the client is using, causing both
client and server to abort the transaction and continue.  This is a
drastic step, but can be useful to prevent a hung client or other bug
from blocking a server indefinitely.

If a client was disconnected during a transaction, the tpc_abort()
call did not properly reset the internal state about the transaction.
The bug caused the next transaction to fail in its tpc_finish().
Also, any ClientDisconnected exceptions raised during tpc_abort() are
ignored.

ZEO logging has been improved by adding more logging for important
events, and changing the logging level for existing messages to a more
appropriate level (usually lower).