[Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.535.2.100

Jeremy Hylton jeremy@zope.com
Wed, 30 Apr 2003 17:21:13 -0400

Update of /cvs-repository/Zope/doc
In directory cvs.zope.org:/tmp/cvs-serv7131

Modified Files:
      Tag: Zope-2_6-branch
Log Message:
Add all the ZODB bug fixes.

=== Zope/doc/CHANGES.txt 1.535.2.99 => 1.535.2.100 ===
--- Zope/doc/CHANGES.txt:1.535.2.99	Mon Mar 31 12:35:58 2003
+++ Zope/doc/CHANGES.txt	Wed Apr 30 17:21:13 2003
@@ -8,6 +8,37 @@
     Bugs Fixed
+      - Database invalidations are processed atomically.  Each
+        transaction will see all the changes caused by an earlier
+        transaction or none of them.  Before this patch, it was
+        possible for a transaction to see invalid data because it saw
+        only a subset of the invalidations.  This is the most likely
+        cause of reported BTrees corruption, where keys were stored in
+        the wrong bucket.  When a BTree bucket splits, the bucket and
+        the bucket's parent are both modified.  If a transaction sees
+        the invalidation for the bucket but not the parent, the BTree
+        in memory will be internally inconsistent and keys can be put
+        in the wrong bucket.  The atomic invalidation fix prevents
+        this problem.
+      - Trying to store an object of a non-integer type into an
+        IIBTree or OIBTree could leave the bucket in a variety of
+        insane states.  For example, trying
+            b[obj] = "I'm a string, not an integer"
+        where b is an OIBTree.  This manifested as a refcount leak in
+        the test suite, but could have been much worse (most likely in
+        real life is that a seemingly arbitrary existing key would "go
+        missing").
+        When deleting the first child of a BTree node with more than
+        one child, a reference to the second child leaked.  This could
+        cause the entire bucket chain to leak (not be collected as
+        garbage despite not being referenced anymore).
+        Other minor BTree leak scenarios were also fixed.
       - Collector #683: WeDAV request without XML preamble
         were not recognized by Zope and raised an exception.
@@ -30,6 +61,24 @@
       - Fixed a whitespace problem in Z2.log (AWStats failed to process
         Zope logfiles)
+      - It was possible for a transaction that failed in tpc_finish()
+        to lose the traceback that caused the failure.  The
+        transaction code was fixed to report the original error as
+        well as any errors that occur while trying to recover from the
+        original error.
+      - Two small bugs were fixed in DemoStorage.  undoLog() did not
+        handle its arguments correctly and pack() could accidentally
+        delete objects created in versions.
+      - Fixed trivial bug in fsrecover that prevented it from working at all.
+      - FileStorage will use fsync() on Windows starting with Python 2.2.3.
+      - FileStorage's commit version was fixed.  It used to stop after
+        the first object, leaving all the other objects in the
+        version.
   Zope 2.6.1