[Zodb-checkins] CVS: ZODB3 - ZEO-NEWS.txt:1.35
Guido van Rossum
guido@python.org
Tue, 17 Sep 2002 18:11:10 -0400
Update of /cvs-repository/ZODB3
In directory cvs.zope.org:/tmp/cvs-serv25535
Modified Files:
ZEO-NEWS.txt
Log Message:
Add news about all changes since I last updated this file.
Add release dates.
=== ZODB3/ZEO-NEWS.txt 1.34 => 1.35 ===
--- ZODB3/ZEO-NEWS.txt:1.34 Thu Sep 12 17:31:08 2002
+++ ZODB3/ZEO-NEWS.txt Tue Sep 17 18:11:10 2002
@@ -1,9 +1,75 @@
Revision History, Zope Enterprise Objects, version 2
- ZEO 2.0 beta 2
+ ZEO 2.0 beta 2 (XXX release date here)
The changes since ZEO 2.0b1 release are:
+ - Read-only fallback option for ClientStorage.
+
+ The ClientStorage class now has a new optional argument,
+ read_only_fallback, defaulting to false. If set to true, the
+ client will accept either read-only servers or read-write
+ servers. If multiple server addresses are given, an available
+ read-write server will be preferred over available read-only
+ servers. When connected to a read-only server, a background
+ thread continues to attempt to open a read-write connection,
+ and when successful, will disconnect an existing read-only
+ connection and reconnect to the read-write server. If this
+ option is false, the original behavior is retained: when the
+ read_only option is false, only read-write servers are
+ acceptable; when the read_only option is true, all servers
+ (read-only or read-write) are acceptable.
+
+ - Connect code refactored.
+
+ The client-side ZRPC code that connects to the server was
+ rewritten almost from scratch (to allow adding the fallback
+ option described above). This code should now do the right
+ thing on Windows systems, at least on Win98 and Win2k
+ (previously, the connect_ex() status wasn't always interpreted
+ correctly).
+
+ - Overlapping calls allowed.
+
+ The limitation that ZRPC calls are serialized in the client is
+ lifted. A multi-threaded client may now make overlapping
+ calls to ClientStorage methods. Three notoriously slow calls
+ (undoInfo(), undoLog(), pack()) are now executed in a separate
+ thread in the server. The limitation to a single outstanding
+ transaction remains though.
+
+ - Locking bug in new_oid() fixed.
+
+ The client-side code in new_oid() would not release its lock
+ if its call to the server's new_oids() raised an exception.
+ This would cause a hard hang upon a subsequent new_oid() call.
+
+ - Fix handling of mid-transaction disconnect.
+
+ When a connection was disconnected while a transaction was in
+ progress, the server-side code attempting to abort the
+ transaction could run into various rare traps. Amongst
+ others, this frequently caused the
+ checkCommitLock2On{Abort,Commit} tests to hang on Win98.
+
+ - Logging cleanup.
+
+ Various log messages were added, removed, or reformatted, or
+ had their priority adjusted. The subsystem string in log
+ messages is now more consistent and never contains spaces.
+ When the subsystem string contains a process id, it is the
+ correct process id (there were cases where the parent's
+ process id continued to be used after a fork() call).
+
+ - Code cleanup.
+
+ Many parts of the code have been cleaned up. The changes
+ include whitespace normalization, spelling fixes, correcting
+ out-of-date comments and docstrings, removing unused imports,
+ attributes and variables, renaming attributes and methods for
+ consistency, and so on. Some refactoring of the test suite
+ was also done.
+
- Fixed possible deadlock in storage server
The locking used in the low-level zrpc mechanism was changed
@@ -17,6 +83,21 @@
messages and chunk long ones even more efficiently, as
suggested by Toby Dickenson.
+ - Cache performance simulation.
+
+ A simulation program (ZEO/simul.py) was added that performs a
+ simulation of the ZEO client cache, given a cache trace file
+ produced by the client cache trace option (see below) and a
+ cache size. The cache simulation will show the effectiveness
+ of a particular cache size given the traffic measured at a
+ site. More information is in the ZEO/README.txt file. (The
+ simulation program also has options to simulate various
+ alternative cache designs. We are looking for volunteers to
+ send us a cache trace file for their site, so we can evaluate
+ the effectiveness of various cache designs given their site's
+ load. Send email to guido@zope.com if you are interested in
+ participating.)
+
- Client cache bugs fixed.
Fixed several bugs in the client cache code that caused the
@@ -31,6 +112,16 @@
= on a cache file flip, the index data for the cache file
that's being overwritten wasn't cleared out.
+ - Fix for abortVersion().
+
+ Different versions of ZODB do different things with the
+ serialnos for abortVersion(). To be safe and avoid giving
+ non-version data with an invalid serialno after an abort
+ version, both the version and non-version data are invalidated.
+
+ This hurts cache effectiveness when a version is aborted, but
+ we expect this will have little practical impact.
+
- Add update() method to ClientStorage
The update() method is used like the sync() method in ZEO 1.
@@ -59,7 +150,7 @@
Setting the environment variable ZEO_CACHE_TRACE to point to a
(writable) file writes a detailed trace of cache requests to
that file. The stats.py program can be used to analyze this
- trace file.
+ trace file. More information is in the ZEO/README.txt file.
- Fixed handling of closed connections in the server.
@@ -84,7 +175,7 @@
- Added a modest unit test suite for the client cache.
- ZEO 2.0 beta 1
+ ZEO 2.0 beta 1 (2002/08/23)
The changes since ZEO 2.0a1 release are:
@@ -92,7 +183,7 @@
The variable ZEO.version is a string identifying the version
in the style of sys.version. The same string is also
- available in ZEO/version.txt for people who want to check
+ available in ZEO/version.txt for people who want to check
without loading the code.
- Fixed performance problem.
@@ -176,15 +267,15 @@
There are only run on Unix.
- ZEO 2.0 alpha 1
+ ZEO 2.0 alpha 1 (2002/05/31)
Brief overview of the differences between ZEO 1.0 and 2.0.
-
+
- New protocol.
ZEO 2 uses a different wire protocol and a different API to
make RPC calls. The new protocol was designed to be flexible
- and simple. It includes an initial handshake to set the
+ and simple. It includes an initial handshake to set the
version number, which should allow future changes to the
protocol while reducing the difficulty of upgrades.