« Changelog History


ZODB v3.3.1.a1 Release Notes

  • 🚀 Release date: 11-Jan-2005

    ZEO client cache

    • 🔧 Collector 1536: The cache-size configuration option for ZEO clients was being ignored. Worse, the client cache size was only one megabyte, much smaller than the advertised default of 20MB. Note that the default is carried over from a time when gigabyte disks were expensive and rare; 20MB is also too small on most modern machines.

    • 🛠 Fixed a nasty bug in cache verification. A persistent ZEO cache uses a disk file, and, when active, has some in-memory data structures too to speed operation. Invalidations processed as part of startup cache verification were reflected in the in-memory data structures, but not correctly in the disk file. So if an object revision was invalidated as part of verification, the object wasn't loaded again before the connection was closed, and the object revision remained in the cache file until the connection was closed, then the next time the cache file was opened it could believe that the stale object revision in the file was actually current.

    • 🛠 Fixed a bug wherein an object removed from the client cache didn't properly mark the file slice it occupied as being available for reuse.

    ZEO

    🌲 Collector 1503: excessive logging. It was possible for a ZEO client to 🌲 log "waiting for cache verification to finish" messages at a very high rate, producing gigabytes of such messages in short order. ClientStorage._wait_sync() was changed to log no more than one such message per 5 minutes.

    persistent

    0️⃣ Collector #1350: ZODB has a default one-thread-per-connection model, and two threads should never do operations on a single connection simultaneously. However, ZODB can't detect violations, and this happened in an early stage of Zope 2.8 development. The low-level ghostify() and unghostify() routines in cPerisistence.c were changed to give 🏗 some help in detecting this when it happens. In a debug build, both abort the process if thread interference is detected. This is extreme, but 🚀 impossible to overlook. In a release build, unghostify() raises SystemError if thread damage is detected; ghostify() ignores the 🚀 problem in a release build (ghostify() is supposed to be so simple that it "can't fail").

    ConflictError

    🆕 New in 3.3, a ConflictError exception may attempt to insert the path to the object's class in its message. However, a ZEO server may not have access to application class implementations, and then the attempt by the server to raise ConflictError could raise ImportError instead while trying to determine the object's class path. This was confusing. The code has been changed to obtain the class path from the object's pickle, without trying to import application modules or classes.

    FileStorage

    Collector 1581: When an attempt to pack a corrupted Data.fs file was made, it was possible for the pack routine to die with a reference to an undefined global while it was trying to raise CorruptedError. It raises CorruptedError, as it always intended, in these cases now.

    Install

    The C header file ring.h is now installed.

    Tools

    • BTrees.check.display() now displays the oids (if any) of the BTree's or TreeSet's constituent objects.