[Zodb-checkins] CVS: ZODB3 - NEWS.txt:1.33.6.27

[Tim Peters]

Update of /cvs-repository/ZODB3
In directory cvs.zope.org:/tmp/cvs-serv25244

Modified Files:
      Tag: Zope-2_7-branch
	NEWS.txt 
Log Message:
Updated news for 3.2.2b1.


=== ZODB3/NEWS.txt 1.33.6.26 => 1.33.6.27 ===
--- ZODB3/NEWS.txt:1.33.6.26	Wed Jun  9 15:14:54 2004
+++ ZODB3/NEWS.txt	Thu Jun 10 15:07:34 2004
@@ -1,14 +1,21 @@
-What's new in ZODB3 3.2.2?
-==========================
+What's new in ZODB3 3.2.1 beta 1?
+=================================
 Release date: DD-MMM-2004
 
 ZODB
 ----
 
-When trying to do recovery to a time earlier than that of the most recent
-full backup, repozo.py failed to find the appropriate files, erroneously
-claiming "No files in repository before <specified time>".  This has
-been repaired.
+Collector #1208:  Infinite loop in cPickleCache.
+If a persistent object had a __del__ method (probably not a good idea
+regardless, but we don't prevent it) that referenced an attribute of
+self, the code to deactivate objects in the cache could get into an
+infinite loop:  ghostifying the object could lead to calling its __del__
+method, the latter would load the object into cache again to
+satsify the attribute reference, the cache would again decide that
+the object should be ghostified, and so on.  The infinite loop no longer
+occurs, but note that objects of this kind still aren't sensible (they're
+effectively immortal).  Thanks to Toby Dickenson for suggesting a nice
+cure.
 
 Under exceedingly unlikely conditions, it was possible for DB.open()
 to block with as few as two threads active.  This was revealed by the
@@ -18,6 +25,22 @@
 was disabled in the BIOS.  It was a legitimate thread race, but without
 hyper-threading it was extremely unlikely to happen.
 
+Storages
+--------
+
+Doc/storages.html changed to record that the experimental BDB-based
+storages are unsupported and will be dropped in ZODB 3.3.  This is due to
+lack of visible interest, and of resources (whether internal or external)
+for support of this code.
+
+Tools
+-----
+
+When trying to do recovery to a time earlier than that of the most recent
+full backup, repozo.py failed to find the appropriate files, erroneously
+claiming "No files in repository before <specified time>".  This has
+been repaired.
+
 Collector #1330:  repozo.py -R can create corrupt .fs.
 When looking for the backup files needed to recreate a Data.fs file,
 repozo could (unintentionally) include its meta .dat files in the list,
@@ -27,17 +50,14 @@
 files with the data extensions repozo.py creates (.fs, .fsz, .deltafs,
 and .deltafsz).  Thanks to James Henderson for the diagnosis.
 
-Collector #1208:  Infinite loop in cPickleCache.
-If a persistent object had a __del__ method (probably not a good idea
-regardless, but we don't prevent it) that referenced an attribute of
-self, the code to deactivate objects in the cache could get into an
-infinite loop:  ghostifying the object could lead to calling its __del__
-method, the latter would load the object into cache again to
-satsify the attribute reference, the cache would again decide that
-the object should be ghostified, and so on.  The infinite loop no longer
-occurs, but note that objects of this kind still aren't sensible (they're
-effectively immortal).  Thanks to Toby Dickenson for suggesting a nice
-cure.
+BTrees
+------
+
+Collector #553:  sporadic Zope crashes
+In rare circumstances, it was possible for BTree conflict resolution
+to be handed three empty BTrees (code needed to fetch an empty BTree
+from the database, add keys to it, then remove them all again, before
+committing the transaction).  This could cause a memory fault in C code.
 
 
 What's new in ZODB3 3.2.1?