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

[Jeremy Hylton]

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

Modified Files:
      Tag: ZODB3-3_1-branch
	NEWS.txt 
Log Message:
Merge tim-loading_oids_status-branch to ZODB 3.1 release branch.

Includes four critical bug fixes.


=== ZODB3/NEWS.txt 1.17.2.27 => 1.17.2.28 ===
--- ZODB3/NEWS.txt:1.17.2.27	Tue May 13 13:59:47 2003
+++ ZODB3/NEWS.txt	Wed Jun 11 19:11:32 2003
@@ -1,3 +1,33 @@
+What's new in ZODB3 3.1.2 beta 2?
+=================================
+
+Fixed a critical race condition in ZEO's cache consistency that could
+cause invalidations to be lost.  A lost invalidation can lead to data
+loss or data corruption.  The specific bug could occur when one client
+loaded an object at the same time another client committed a change to
+the object.  It was possible for the zrpc layer to re-order the
+response to the load and the invalidation, effectively causing the
+invalidation to be lost.  The bug was fixed by delaying the handling
+of invalidations for an object while a load for the same object is in
+progress. 
+
+Fix a bug in conflict resolution that failed to ghostify an object if
+it was involved in a conflict.  (This code may be redundant, but it
+has been fixed regardless.)
+
+The ZEO server was fixed so that it does not perform any I/O until all
+of a transactions invalidations are queued.  If it performs I/O in the
+middle of sending invalidations, it would be possible to overlap a
+load from a client with the invalidation being sent to it.
+
+The ZEO cache now handles invalidations atomically.  This is the same
+sort of bug that is described in the 3.1.2b1 section below, but it
+affects the ZEO cache.
+
+Fixed several serious bugs in fsrecover that caused it to fail
+catastrophically in certain cases because it thought it had found a
+checkpoint (status "c") record when it was in the middle of the file.
+
 What's new in ZODB3 3.1.2 beta 1?
 =================================