File contents
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.3.8: http://docutils.sourceforge.net/" />
<title></title>
<link rel="stylesheet" href="default.css" type="text/css" />
</head>
<body>
<div class="document">
<div class="section" id="what-s-new-in-zodb3-3-3-1">
<h1><a name="what-s-new-in-zodb3-3-3-1">What's new in ZODB3 3.3.1?</a></h1>
<p>Release date: 14-Apr-2005</p>
<p>Please note that ZODB 3.3.1 final is expected to be the last release in
the 3.3.1 line. Zope 2.8 and Zope3 development have moved on to the
ZODB 3.4 line.</p>
<div class="section" id="tests">
<h2><a name="tests">Tests</a></h2>
<p>The various flavors of the <tt class="docutils literal"><span class="pre">check2ZODBThreads</span></tt> and <tt class="docutils literal"><span class="pre">check7ZODBThreads</span></tt>
tests are much less likely to suffer sproadic failures now.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-1c1">
<h1><a name="what-s-new-in-zodb3-3-3-1c1">What's new in ZODB3 3.3.1c1?</a></h1>
<p>Release date: 01-Apr-2005</p>
<div class="section" id="btrees">
<h2><a name="btrees">BTrees</a></h2>
<p>Collector #1734: BTrees conflict resolution leads to index inconsistencies.</p>
<p>Silent data loss could occur due to BTree conflict resolution when one
transaction T1 added a new key to a BTree containing at least three buckets,
and a concurrent transaction T2 deleted all keys in the bucket to which the
new key was added. Conflict resolution then created a bucket containing the
newly added key, but the bucket remained isolated, disconnected from the
BTree. In other words, the committed BTree didn't contain the new key added by
T1. Conflict resolution doesn't have enough information to repair this,
so <tt class="docutils literal"><span class="pre">ConflictError</span></tt> is now raised in such cases.</p>
</div>
<div class="section" id="zeo">
<h2><a name="zeo">ZEO</a></h2>
<p>Repaired subtle race conditions in establishing ZEO connections, both client-
and server-side. These account for intermittent cases where ZEO failed
to make a connection (or reconnection), accompanied by a log message showing
an error caught in <tt class="docutils literal"><span class="pre">asyncore</span></tt> and having a traceback ending with:</p>
<blockquote>
<tt class="docutils literal"><span class="pre">UnpicklingError:</span> <span class="pre">invalid</span> <span class="pre">load</span> <span class="pre">key,</span> <span class="pre">'Z'.</span></tt></blockquote>
<p>or:</p>
<blockquote>
<tt class="docutils literal"><span class="pre">ZRPCError:</span> <span class="pre">bad</span> <span class="pre">handshake</span> <span class="pre">'(K\x00K\x00U\x0fgetAuthProtocol)t.'</span></tt></blockquote>
<p>or:</p>
<blockquote>
<tt class="docutils literal"><span class="pre">error:</span> <span class="pre">(9,</span> <span class="pre">'Bad</span> <span class="pre">file</span> <span class="pre">descriptor')</span></tt></blockquote>
<p>or an <tt class="docutils literal"><span class="pre">AttributeError</span></tt>.</p>
<p>These were exacerbated when running the test suite, because of an unintended
busy loop in the test scaffolding, which could starve the thread trying to
make a connection. The ZEO reconnection tests may run much faster now,
depending on platform, and should suffer far fewer (if any) intermittent
"timed out waiting for storage to connect" failures.</p>
</div>
<div class="section" id="zeo-protocol-and-compatibility">
<h2><a name="zeo-protocol-and-compatibility">ZEO protocol and compatibility</a></h2>
<p>ZODB 3.3 introduced multiversion concurrency control (MVCC), which required
changes to the ZEO protocol. The first 3.3 release should have increased
the internal ZEO protocol version number (used by ZEO protocol negotiation
when a client connects), but neglected to. This has been repaired.</p>
<p>Compatibility between pre-3.3 and post-3.3 ZEO clients and servers remains
very limited. See the newly updated <tt class="docutils literal"><span class="pre">Compatibility</span></tt> section in
<tt class="docutils literal"><span class="pre">README.txt</span></tt> for details.</p>
</div>
<div class="section" id="filestorage">
<h2><a name="filestorage">FileStorage</a></h2>
<ul>
<li><p class="first">The <tt class="docutils literal"><span class="pre">.store()</span></tt> and <tt class="docutils literal"><span class="pre">.restore()</span></tt> methods didn't update the storage's
belief about the largest oid in use when passed an oid larger than the
largest oid the storage already knew about. Because <tt class="docutils literal"><span class="pre">.restore()</span></tt> in
particular is used by <tt class="docutils literal"><span class="pre">copyTransactionsFrom()</span></tt>, and by the first stage
of ZRS recovery, a large database could be created that believed the only
oid in use was oid 0 (the special oid reserved for the root object). In
rare cases, it could go on from there assigning duplicate oids to new
objects, starting over from oid 1 again. This has been repaired. A
new <tt class="docutils literal"><span class="pre">set_max_oid()</span></tt> method was added to the <tt class="docutils literal"><span class="pre">BaseStorage</span></tt> class so
that derived storages can update the largest oid in use in a threadsafe
way.</p>
</li>
<li><p class="first">A FileStorage's index file tried to maintain the index's largest oid as a
separate piece of data, incrementally updated over the storage's lifetime.
This scheme was more complicated than necessary, so was also more brittle
and slower than necessary. It indirectly participated in a rare but
critical bug: when a FileStorage was created via
<tt class="docutils literal"><span class="pre">copyTransactionsFrom()</span></tt>, the "maximum oid" saved in the index file was
always 0. Use that FileStorage, and it could then create "new" oids
starting over at 0 again, despite that those oids were already in use by
old objects in the database. Packing a FileStorage has no reason to
try to update the maximum oid in the index file either, so this kind of
damage could (and did) persist even across packing.</p>
<p>The index file's maximum-oid data is ignored now, but is still written
out so that <tt class="docutils literal"><span class="pre">.index</span></tt> files can be read by older versions of ZODB.
Finding the true maximum oid is done now by exploiting that the main
index is really a kind of BTree (long ago, this wasn't true), and finding
the largest key in a BTree is inexpensive.</p>
</li>
<li><p class="first">A FileStorage's index file could be updated on disk even if the storage
was opened in read-only mode. That bug has been repaired.</p>
</li>
<li><p class="first">An efficient <tt class="docutils literal"><span class="pre">maxKey()</span></tt> implementation was added to class <tt class="docutils literal"><span class="pre">fsIndex</span></tt>.</p>
</li>
</ul>
</div>
<div class="section" id="pickle-in-memory-connection-cache">
<h2><a name="pickle-in-memory-connection-cache">Pickle (in-memory Connection) Cache</a></h2>
<p>You probably never saw this exception:</p>
<blockquote>
<tt class="docutils literal"><span class="pre">ValueError:</span> <span class="pre">Can</span> <span class="pre">not</span> <span class="pre">re-register</span> <span class="pre">object</span> <span class="pre">under</span> <span class="pre">a</span> <span class="pre">different</span> <span class="pre">oid</span></tt></blockquote>
<p>It's been changed to say what it meant:</p>
<blockquote>
<tt class="docutils literal"><span class="pre">ValueError:</span> <span class="pre">A</span> <span class="pre">different</span> <span class="pre">object</span> <span class="pre">already</span> <span class="pre">has</span> <span class="pre">the</span> <span class="pre">same</span> <span class="pre">oid</span></tt></blockquote>
<p>This happens if an attempt is made to add distinct objects to the cache
that have the same oid (object identifier). ZODB should never do this,
but it's possible for application code to force such an attempt.</p>
</div>
<div class="section" id="persistentmapping-and-persistentlist">
<h2><a name="persistentmapping-and-persistentlist">PersistentMapping and PersistentList</a></h2>
<p>Backward compatibility code has been added so that the sanest of the
ZODB 3.2 dotted paths for <tt class="docutils literal"><span class="pre">PersistentMapping</span></tt> and <tt class="docutils literal"><span class="pre">PersistentList</span></tt>
resolve. These are still preferred:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">from</span> <span class="pre">persistent.list</span> <span class="pre">import</span> <span class="pre">PersistentList</span></tt></li>
<li><tt class="docutils literal"><span class="pre">from</span> <span class="pre">persistent.mapping</span> <span class="pre">import</span> <span class="pre">PersistentMapping</span></tt></li>
</ul>
<p>but these work again too:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">from</span> <span class="pre">ZODB.PersistentList</span> <span class="pre">import</span> <span class="pre">PersistentList</span></tt></li>
<li><tt class="docutils literal"><span class="pre">from</span> <span class="pre">ZODB.PersistentMapping</span> <span class="pre">import</span> <span class="pre">PersistentMapping</span></tt></li>
</ul>
</div>
<div class="section" id="id1">
<h2><a name="id1">BTrees</a></h2>
<p>The BTrees interface file neglected to document the optional
<tt class="docutils literal"><span class="pre">excludemin</span></tt> and <tt class="docutils literal"><span class="pre">excludemax</span></tt> arguments to the <tt class="docutils literal"><span class="pre">keys()</span></tt>, <tt class="docutils literal"><span class="pre">values()</span></tt>
and <tt class="docutils literal"><span class="pre">items()</span></tt> methods. Appropriate changes were merged in from the
ZODB4 BTrees interface file.</p>
</div>
<div class="section" id="tools">
<h2><a name="tools">Tools</a></h2>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">mkzeoinst.py</span></tt>'s default port number changed from to 9999 to 8100, to
match the example in Zope's <tt class="docutils literal"><span class="pre">zope.conf</span></tt>.</li>
</ul>
</div>
<div class="section" id="fsindex">
<h2><a name="fsindex">fsIndex</a></h2>
<p>An efficient <tt class="docutils literal"><span class="pre">maxKey()</span></tt> method was implemented for the <tt class="docutils literal"><span class="pre">fsIndex</span></tt> class.
This makes it possible to determine the largest oid in a <tt class="docutils literal"><span class="pre">FileStorage</span></tt>
index efficiently, directly, and reliably, replacing a more delicate scheme
that tried to keep track of this by saving an oid high water mark in the
index file and incrementally updating it.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-1a1">
<h1><a name="what-s-new-in-zodb3-3-3-1a1">What's new in ZODB3 3.3.1a1?</a></h1>
<p>Release date: 11-Jan-2005</p>
<div class="section" id="zeo-client-cache">
<h2><a name="zeo-client-cache">ZEO client cache</a></h2>
<ul class="simple">
<li>Collector 1536: The <tt class="docutils literal"><span class="pre">cache-size</span></tt> 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.</li>
<li>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.</li>
<li>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.</li>
</ul>
</div>
<div class="section" id="id2">
<h2><a name="id2">ZEO</a></h2>
<p>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.
<tt class="docutils literal"><span class="pre">ClientStorage._wait_sync()</span></tt> was changed to log no more than one
such message per 5 minutes.</p>
</div>
<div class="section" id="persistent">
<h2><a name="persistent">persistent</a></h2>
<p>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 <tt class="docutils literal"><span class="pre">ghostify()</span></tt>
and <tt class="docutils literal"><span class="pre">unghostify()</span></tt> routines in <tt class="docutils literal"><span class="pre">cPerisistence.c</span></tt> 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, <tt class="docutils literal"><span class="pre">unghostify()</span></tt> raises
<tt class="docutils literal"><span class="pre">SystemError</span></tt> if thread damage is detected; <tt class="docutils literal"><span class="pre">ghostify()</span></tt> ignores the
problem in a release build (<tt class="docutils literal"><span class="pre">ghostify()</span></tt> is supposed to be so simple that
it "can't fail").</p>
</div>
<div class="section" id="conflicterror">
<h2><a name="conflicterror">ConflictError</a></h2>
<p>New in 3.3, a <tt class="docutils literal"><span class="pre">ConflictError</span></tt> 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 <tt class="docutils literal"><span class="pre">ConflictError</span></tt> could raise <tt class="docutils literal"><span class="pre">ImportError</span></tt> 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.</p>
</div>
<div class="section" id="id3">
<h2><a name="id3">FileStorage</a></h2>
<p>Collector 1581: When an attempt to pack a corrupted <tt class="docutils literal"><span class="pre">Data.fs</span></tt> 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 <tt class="docutils literal"><span class="pre">CorruptedError</span></tt>. It
raises <tt class="docutils literal"><span class="pre">CorruptedError</span></tt>, as it always intended, in these cases now.</p>
</div>
<div class="section" id="install">
<h2><a name="install">Install</a></h2>
<p>The C header file <tt class="docutils literal"><span class="pre">ring.h</span></tt> is now installed.</p>
</div>
<div class="section" id="id4">
<h2><a name="id4">Tools</a></h2>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">BTrees.check.display()</span></tt> now displays the oids (if any) of the
BTree's or TreeSet's constituent objects.</li>
</ul>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3">
<h1><a name="what-s-new-in-zodb3-3-3">What's new in ZODB3 3.3?</a></h1>
<p>Release date: 06-Oct-2004</p>
<div class="section" id="id5">
<h2><a name="id5">ZEO</a></h2>
<p>The encoding of RPC calls between server and client was being done
with protocol 0 ("text mode") pickles, which could require sending
four times as many bytes as necessary. Protocol 1 pickles are used
now. Thanks to Andreas Jung for the diagnosis and cure.</p>
</div>
<div class="section" id="zodb-component-xml">
<h2><a name="zodb-component-xml">ZODB/component.xml</a></h2>
<p><tt class="docutils literal"><span class="pre">cache-size</span></tt> parameters were changed from type <tt class="docutils literal"><span class="pre">integer</span></tt> to
type <tt class="docutils literal"><span class="pre">byte-size</span></tt>. This allows you to specify, for example,
"<tt class="docutils literal"><span class="pre">cache-size</span> <span class="pre">20MB</span></tt>" to get a 20 megabyte cache.</p>
</div>
<div class="section" id="transaction">
<h2><a name="transaction">transaction</a></h2>
<p>The deprecation warning for <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt> was changed to
point to the caller, instead of to <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt> itself.</p>
</div>
<div class="section" id="connection">
<h2><a name="connection">Connection</a></h2>
<p>Restored Connection's private <tt class="docutils literal"><span class="pre">_opened</span></tt> attribute. This was still
referenced by <tt class="docutils literal"><span class="pre">DB.connectionDebugInfo()</span></tt>, and Zope 2 calls the latter.</p>
</div>
<div class="section" id="id6">
<h2><a name="id6">FileStorage</a></h2>
<p>Collector #1517: History tab for ZPT does not work. <tt class="docutils literal"><span class="pre">FileStorage.history()</span></tt>
was reading the user, description, and extension fields out of the object
pickle, due to starting the read at a wrong location. Looked like
cut-and-paste repetition of the same bug in <tt class="docutils literal"><span class="pre">FileStorage.FileIterator</span></tt>
noted in the news for 3.3c1.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-release-candidate-1">
<h1><a name="what-s-new-in-zodb3-3-3-release-candidate-1">What's new in ZODB3 3.3 release candidate 1?</a></h1>
<p>Release date: 14-Sep-2004</p>
<div class="section" id="id7">
<h2><a name="id7">Connection</a></h2>
<p>ZODB intends to raise <tt class="docutils literal"><span class="pre">ConnnectionStateError</span></tt> if an attempt is made to
close a connection while modifications are pending (the connection is
involved in a transaction that hasn't been <tt class="docutils literal"><span class="pre">abort()</span></tt>'ed or
<tt class="docutils literal"><span class="pre">commit()</span></tt>'ed). It was missing the case where the only pending
modifications were made in subtransactions. This has been fixed. If an
attempt to close a connection with pending subtransactions is made now:</p>
<pre class="literal-block">
ConnnectionStateError: Cannot close a connection with a pending subtransaction
</pre>
<p>is raised.</p>
</div>
<div class="section" id="id8">
<h2><a name="id8">transaction</a></h2>
<ul>
<li><p class="first">Transactions have new, backward-incompatible behavior in one respect:
if a <tt class="docutils literal"><span class="pre">Transaction.commit()</span></tt>, <tt class="docutils literal"><span class="pre">Transaction.commit(False)</span></tt>, or
<tt class="docutils literal"><span class="pre">Transaction.commit(True)</span></tt> raised an exception, prior behavior was that
the transaction effectively aborted, and a new transaction began.
A primary bad consequence was that, if in a sequence of subtransaction
commits, one of the commits failed but the exception was suppressed,
all changes up to and including the failing commit were lost, but
later subtransaction commits in the sequence got no indication that
something had gone wrong, nor did the final (top level) commit. This
could easily lead to inconsistent data being committed, from the
application's point of view.</p>
<p>The new behavior is that a failing commit "sticks" until explicitly
cleared. Now if an exception is raised by a <tt class="docutils literal"><span class="pre">commit()</span></tt> call (whether
subtransaction or top level) on a Transaction object <tt class="docutils literal"><span class="pre">T</span></tt>:</p>
<blockquote>
<ul class="simple">
<li>Pending changes are aborted, exactly as they were for a failing
commit before.</li>
<li>But <tt class="docutils literal"><span class="pre">T</span></tt> remains the current transaction object (if <tt class="docutils literal"><span class="pre">tm</span></tt> is <tt class="docutils literal"><span class="pre">T</span></tt>'s
transaction manger, <tt class="docutils literal"><span class="pre">tm.get()</span></tt> continues to return <tt class="docutils literal"><span class="pre">T</span></tt>).</li>
<li>All subsequent attempts to do <tt class="docutils literal"><span class="pre">T.commit()</span></tt>, <tt class="docutils literal"><span class="pre">T.join()</span></tt>, or
<tt class="docutils literal"><span class="pre">T.register()</span></tt> raise the new <tt class="docutils literal"><span class="pre">TransactionFailedError</span></tt> exception.
Note that if you try to modify a persistent object, that object's
resource manager (usually a <tt class="docutils literal"><span class="pre">Connection</span></tt> object) will attempt to
<tt class="docutils literal"><span class="pre">join()</span></tt> the failed transaction, and <tt class="docutils literal"><span class="pre">TransactionFailedError</span></tt>
will be raised right away.</li>
</ul>
</blockquote>
<p>So after a transaction or subtransaction commit fails, that must be
explicitly cleared now, either by invoking <tt class="docutils literal"><span class="pre">abort()</span></tt> on the transaction
object, or by invoking <tt class="docutils literal"><span class="pre">begin()</span></tt> on its transaction manager.</p>
</li>
<li><p class="first">Some explanations of new transaction features in the 3.3a3 news
were incorrect, and this news file has been retroactively edited to
repair that. See news for 3.3a3 below.</p>
</li>
<li><p class="first">If ReadConflictError was raised by an attempt to load an object with a
<tt class="docutils literal"><span class="pre">_p_independent()</span></tt> method that returned false, attempting to commit the
transaction failed to (re)raise ReadConflictError for that object. Note
that ZODB intends to prevent committing a transaction in which a
ReadConflictError occurred; this was an obscure case it missed.</p>
</li>
<li><p class="first">Growing pains: ZODB 3.2 had a bug wherein <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt> didn't
abort the current transaction if the only pending changes were in a
subtransaction. In ZODB 3.3, it's intended that a transaction manager be
used to effect <tt class="docutils literal"><span class="pre">begin()</span></tt> (instead of invoking <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt>),
and calling <tt class="docutils literal"><span class="pre">begin()</span></tt> on a transaction manager didn't have this old
bug. However, <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt> still exists in 3.3, and it had a
worse bug: it never aborted the transaction (not even if changes were
pending outside of subtransactions). <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt> has been
changed to abort the transaction. <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt> is also
deprecated. Don't use it. Use <tt class="docutils literal"><span class="pre">begin()</span></tt> on the relevant transaction
manager instead. For example,</p>
<blockquote>
<pre class="doctest-block">
>>> import transaction
>>> txn = transaction.begin() # start a txn using the default TM
</pre>
</blockquote>
<p>if using the default <tt class="docutils literal"><span class="pre">ThreadTransactionManager</span></tt> (see news for 3.3a3
below). In 3.3, it's intended that a single <tt class="docutils literal"><span class="pre">Transaction</span></tt> object is
used for exactly one transaction. So, unlike as in 3.2, when somtimes
<tt class="docutils literal"><span class="pre">Transaction</span></tt> objects were reused across transactions, but sometimes
weren't, when you do <tt class="docutils literal"><span class="pre">Transaction.begin()</span></tt> in 3.3 a brand new
transaction object is created. That's why this use is deprecated. Code
of the form:</p>
<blockquote>
<pre class="doctest-block">
>>> txn = transaction.get()
>>> ...
>>> txn.begin()
>>> ...
>>> txn.commit()
</pre>
</blockquote>
<p>can't work as intended in 3.3, because <tt class="docutils literal"><span class="pre">txn</span></tt> is no longer the current
<tt class="docutils literal"><span class="pre">Transaction</span></tt> object the instant <tt class="docutils literal"><span class="pre">txn.begin()</span></tt> returns.</p>
</li>
</ul>
</div>
<div class="section" id="id9">
<h2><a name="id9">BTrees</a></h2>
<p>The BTrees __init__.py file is now just a comment. It had been trying
to set up support for (long gone) "int sets", and to import an old
version of Zope's Interface package, which doesn't even ship with ZODB.
The latter in particular created problems, at least clashing with
PythonCAD's Interface package.</p>
</div>
<div class="section" id="posexception">
<h2><a name="posexception">POSException</a></h2>
<p>Collector #1488 (TemporaryStorage -- going backward in time). This
confusion was really due to that the detail on a ConflictError exception
didn't make sense. It called the current revision "was", and the old
revision "now". The detail is much more informative now. For example,
if the exception said:</p>
<pre class="literal-block">
ConflictError: database conflict error (oid 0xcb22,
serial was 0x03441422948b4399, now 0x034414228c3728d5)
</pre>
<p>before, it now says:</p>
<pre class="literal-block">
ConflictError: database conflict error (oid 0xcb22,
serial this txn started with 0x034414228c3728d5 2002-04-14 20:50:32.863000,
serial currently committed 0x03441422948b4399 2002-04-14 20:50:34.815000)
</pre>
</div>
<div class="section" id="id10">
<h2><a name="id10">ConflictError</a></h2>
<p>The undocumented <tt class="docutils literal"><span class="pre">get_old_serial()</span></tt> and <tt class="docutils literal"><span class="pre">get_new_serial()</span></tt> methods
were swapped (the first returned the new serial, and the second returned
the old serial).</p>
</div>
<div class="section" id="id11">
<h2><a name="id11">Tools</a></h2>
<p><tt class="docutils literal"><span class="pre">FileStorage.FileIterator</span></tt> was confused about how to read a transaction's
user and description fields, which caused several tools to display
binary gibberish for these values.</p>
<p><tt class="docutils literal"><span class="pre">ZODB.utils.oid_repr()</span></tt> changed to add a leading "0x", and to strip
leading zeroes. This is used, e.g., in the detail of a <tt class="docutils literal"><span class="pre">POSKeyError</span></tt>
exception, to identify the missing oid. Before, the output was ambiguous.
For example, oid 17 was displayed as 0000000000000011. As a Python
integer, that's octal 9. Or was it meant to be decimal 11? Or was it
meant to be hex? Now it displays as 0x11.</p>
<p>fsrefs.py:</p>
<blockquote>
<p>When run with <tt class="docutils literal"><span class="pre">-v</span></tt>, produced tracebacks for objects whose creation was
merely undone. This was confusing. Tracebacks are now produced only
if there's "a real" problem loading an oid.</p>
<p>If the current revision of object O refers to an object P whose
creation has been undone, this is now identified as a distinct case.</p>
<p>Captured and ignored most attempts to stop it via Ctrl+C. Repaired.</p>
<p>Now makes two passes, so that an accurate report can be given of all
invalid references.</p>
</blockquote>
<p><tt class="docutils literal"><span class="pre">analyze.py</span></tt> produced spurious "len of unsized object" messages when
finding a data record for an object uncreation or version abort. These
no longer appear.</p>
<p><tt class="docutils literal"><span class="pre">fsdump.py</span></tt>'s <tt class="docutils literal"><span class="pre">get_pickle_metadata()</span></tt> function (which is used by several
tools) was confused about what to do when the ZODB pickle started with
a pickle <tt class="docutils literal"><span class="pre">GLOBAL</span></tt> opcode. It actually loaded the class then, which it
intends never to do, leading to stray messages on stdout when the class
wasn't available, and leading to a strange return value even when it was
available (the repr of the type object was returned as "the module name",
and an empty string was returned as "the class name"). This has been
repaired.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-beta-2">
<h1><a name="what-s-new-in-zodb3-3-3-beta-2">What's new in ZODB3 3.3 beta 2</a></h1>
<p>Release date: 13-Aug-2004</p>
<div class="section" id="transaction-managers">
<h2><a name="transaction-managers">Transaction Managers</a></h2>
<p>Zope3-dev Collector #139: Memory leak involving buckets and connections</p>
<p>The transaction manager internals effectively made every Connection
object immortal, except for those explicitly closed. Since typical
practice is not to close connections explicitly (and closing a DB
happens not to close the connections to it -- although that may
change), this caused massive memory leaks when many connections were
opened. The transaction manager internals were reworked to use weak
references instead, so that connection memory (and other registered
synch objects) now get cleaned up when nothing other than the
transaction manager knows about them.</p>
</div>
<div class="section" id="storages">
<h2><a name="storages">Storages</a></h2>
<p>Collector #1327: FileStorage init confused by time travel</p>
<p>If the system clock "went backwards" a long time between the times a
FileStorage was closed and reopened, new transaction ids could be
smaller than transaction ids already in the storage, violating a
key invariant. Now transaction ids are guaranteed to be increasing
even when this happens. If time appears to have run backwards at all
when a FileStorage is opened, a new message saying so is logged at
warning level; if time appears to have run backwards at least 30
minutes, the message is logged at critical level (and you should
investigate to find and repair the true cause).</p>
</div>
<div class="section" id="id12">
<h2><a name="id12">Tools</a></h2>
<p>repozo.py: Thanks to a suggestion from Toby Dickenson, backups
(whether incremental or full) are first written to a temp file now,
which is fsync'ed at the end, and only after that succeeds is the
file renamed to YYYY-MM-DD-HH-MM-SS.ext form. In case of a system
crash during a repozo backup, this at least makes it much less
likely that a backup file with incomplete or incorrect data will be
left behind.</p>
<p>fsrefs.py: Fleshed out the module docstring, and repaired a bug
wherein spurious error msgs could be produced after reporting a
problem with an unloadable object.</p>
</div>
<div class="section" id="test-suite">
<h2><a name="test-suite">Test suite</a></h2>
<p>Collector #1397: testTimeStamp fails on FreeBSD</p>
<blockquote>
The BSD distributions are unique in that their mktime()
implementation usually ignores the input tm_isdst value. Test
checkFullTimeStamp() was sensitive to this platform quirk.</blockquote>
<p>Reworked the way some of the ZEO tests use threads, so that unittest is
more likely to notice the real cause of a failure (which usually occurs in
a thread), and less likely to latch on to spurious problems resulting from
the real failure.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-beta-1">
<h1><a name="what-s-new-in-zodb3-3-3-beta-1">What's new in ZODB3 3.3 beta 1</a></h1>
<p>Release date: 07-Jun-2004</p>
<p>3.3b1 is the first ZODB release built using the new zpkg tools:</p>
<blockquote>
<a class="reference" href="http://zope.org/Members/fdrake/zpkgtools/">http://zope.org/Members/fdrake/zpkgtools/</a></blockquote>
<p>This appears to have worked very well. The structure of the tarball
release differs from previous releases because of it, and the set of
installed files includes some that were not installed in previous
releases. That shouldn't create problems, so let us know if it does!
We'll fine-tune this for the next release.</p>
<div class="section" id="id13">
<h2><a name="id13">BTrees</a></h2>
<p>Fixed bug indexing BTreeItems objects with negative indexes. This
caused reverse iteration to return each item twice. Thanks to Casey
Duncan for the fix.</p>
</div>
<div class="section" id="zodb">
<h2><a name="zodb">ZODB</a></h2>
<p>Methods removed from the database (ZODB.DB.DB) class: cacheStatistics(),
cacheMeanAge(), cacheMeanDeac(), and cacheMeanDeal(). These were
undocumented, untested, and unused. The first always returned an empty
tuple, and the rest always returned None.</p>
<p>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.</p>
<p>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,
or random files of any kind created by the user in the backup directory.
These would then get copied verbatim into the reconstructed file, filling
parts with junk. Repaired by filtering the file list to include only
files with the data extensions repozo.py creates (.fs, .fsz, .deltafs,
and .deltafsz). Thanks to James Henderson for the diagnosis.</p>
<p>fsrecover.py couldn't work, because it referenced attributes that no
longer existed after the MVCC changes. Repaired that, and added new
tests to ensure it continues working.</p>
<p>Collector #1309: The reference counts reported by DB.cacheExtremeDetails()
for ghosts were one too small. Thanks to Dieter Maurer for the diagnosis.</p>
<p>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.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-alpha-3">
<h1><a name="what-s-new-in-zodb3-3-3-alpha-3">What's new in ZODB3 3.3 alpha 3</a></h1>
<p>Release date: 16-Apr-2004</p>
<div class="section" id="id14">
<h2><a name="id14">transaction</a></h2>
<p>There is a new transaction package, which provides new interfaces for
application code and for the interaction between transactions and
resource managers.</p>
<p>The top-level transaction package has functions <tt class="docutils literal"><span class="pre">commit()</span></tt>, <tt class="docutils literal"><span class="pre">abort()</span></tt>,
<tt class="docutils literal"><span class="pre">get()</span></tt>, and <tt class="docutils literal"><span class="pre">begin()</span></tt>. They should be used instead of the magic
<tt class="docutils literal"><span class="pre">get_transaction()</span></tt> builtin, which will be deprecated. For example:</p>
<blockquote>
<pre class="doctest-block">
>>> get_transaction().commit()
</pre>
</blockquote>
<p>should now be written as</p>
<blockquote>
<pre class="doctest-block">
>>> import transaction
>>> transaction.commit()
</pre>
</blockquote>
<p>The new API provides explicit transaction manager objects. A transaction
manager (TM) is responsible for associating resource managers with a
"current" transaction. The default TM, implemented by class
<tt class="docutils literal"><span class="pre">ThreadedTransactionManager</span></tt>, assigns each thread its own current
transaction. This default TM is available as <tt class="docutils literal"><span class="pre">transaction.manager</span></tt>. The
<tt class="docutils literal"><span class="pre">TransactionManager</span></tt> class assigns all threads to the same transaction,
and is an explicit replacement for the <tt class="docutils literal"><span class="pre">Connection.setLocalTransaction()</span></tt>
method:</p>
<p>A transaction manager instance can be passed as the txn_mgr argument to
<tt class="docutils literal"><span class="pre">DB.open()</span></tt>. If you do, the connection will use the specified
transaction manager instead of the default TM. The current transaction is
obtained by calling <tt class="docutils literal"><span class="pre">get()</span></tt> on a TM. For example:</p>
<blockquote>
<pre class="doctest-block">
>>> tm = transaction.TransactionManager()
>>> cn = db.open(txn_mgr=tm)
[...]
>>> tm.get().commit()
</pre>
</blockquote>
<p>The <tt class="docutils literal"><span class="pre">setLocalTransaction()</span></tt> and <tt class="docutils literal"><span class="pre">getTransaction()</span></tt> methods of
Connection are deprecated. Use an explicit TM passed via <tt class="docutils literal"><span class="pre">txn_mgr=</span></tt> to
<tt class="docutils literal"><span class="pre">DB.open()</span></tt> instead. The <tt class="docutils literal"><span class="pre">setLocalTransaction()</span></tt> method still works,
but it returns a TM instead of a Transaction.</p>
<p>A TM creates Transaction objects, which are used for exactly one
transaction. Transaction objects still have <tt class="docutils literal"><span class="pre">commit()</span></tt>, <tt class="docutils literal"><span class="pre">abort()</span></tt>,
<tt class="docutils literal"><span class="pre">note()</span></tt>, <tt class="docutils literal"><span class="pre">setUser()</span></tt>, and <tt class="docutils literal"><span class="pre">setExtendedInfo()</span></tt> methods.</p>
<p>Resource managers, e.g. Connection or RDB adapter, should use a
Transaction's <tt class="docutils literal"><span class="pre">join()</span></tt> method instead of its <tt class="docutils literal"><span class="pre">register()</span></tt> method. An
object that calls <tt class="docutils literal"><span class="pre">join()</span></tt> manages its own resources. An object that
calls <tt class="docutils literal"><span class="pre">register()</span></tt> expects the TM to manage the objects.</p>
<p>Data managers written against the ZODB 4 transaction API are now
supported in ZODB 3.</p>
</div>
<div class="section" id="id15">
<h2><a name="id15">persistent</a></h2>
<p>A database can now contain persistent weak references. An object that
is only reachable from persistent weak references will be removed by
pack().</p>
<p>The persistence API now distinguishes between deactivation and
invalidation. This change is intended to support objects that can't
be ghosts, like persistent classes. Deactivation occurs when a user
calls _p_deactivate() or when the cache evicts objects because it is
full. Invalidation occurs when a transaction updates the object. An
object that can't be a ghost must load new state when it is
invalidated, but can ignore deactivation.</p>
<p>Persistent objects can implement a __getnewargs__() method that will
be used to provide arguments that should be passed to __new__() when
instances (including ghosts) are created. An object that implements
__getnewargs__() must be loaded from storage even to create a ghost.</p>
<p>There is new support for writing hooks like __getattr__ and
__getattribute__. The new hooks require that user code call special
persistence methods like _p_getattr() inside their hook. See the ZODB
programming guide for details.</p>
<p>The format of serialized persistent references has changed; that is,
the on-disk format for references has changed. The old format is
still supported, but earlier versions of ZODB will not be able to read
the new format.</p>
</div>
<div class="section" id="id16">
<h2><a name="id16">ZODB</a></h2>
<p>Closing a ZODB Connection while it is registered with a transaction,
e.g. has pending modifications, will raise a ConnnectionStateError.
Trying to load objects from or store objects to a closed connection
will also raise a ConnnectionStateError.</p>
<p>ZODB connections are synchronized on commit, even when they didn't
modify objects. This feature assumes that the thread that opened the
connection is also the thread that uses it. If not, this feature will
cause problems. It can be disabled by passing synch=False to open().</p>
<p>New broken object support.</p>
<p>New add() method on Connection. User code should not assign the
_p_jar attribute of a new persistent object directly; a deprecation
warning is issued in this case.</p>
<p>Added a get() method to Connection as a preferred synonym for
__getitem__().</p>
<p>Several methods and/or specific optional arguments of methods have
been deprecated. The cache_deactivate_after argument used by DB() and
Connection() is deprecated. The DB methods getCacheDeactivateAfter(),
getVersionCacheDeactivateAfter(), setCacheDeactivateAfter(), and
setVersionCacheDeactivateAfter() are also deprecated.</p>
<p>The old-style undo() method was removed from the storage API, and
transactionalUndo() was renamed to undo().</p>
<p>The BDBStorages are no longer distributed with ZODB.</p>
<p>Fixed a serious bug in the new pack implementation. If pack was
called on the storage and passed a time earlier than a previous pack
time, data could be lost. In other words, if there are any two pack
calls, where the time argument passed to the second call was earlier
than the first call, data loss could occur. The bug was fixed by
causing the second call to raise a StorageError before performing any
work.</p>
<p>Fixed a rare bug in pack: if a pack started during a small window of
time near the end of a concurrent transaction's commit, it was possible
for the pack attempt to raise a spurious</p>
<blockquote>
CorruptedError: ... transaction with checkpoint flag set</blockquote>
<p>exception. This did no damage to the database, or to the transaction
in progress, but no pack was performed then.</p>
<p>By popular demand, FileStorage.pack() no longer propagates a</p>
<blockquote>
FileStorageError: The database has already been packed to a
later time or no changes have been made since the last pack</blockquote>
<p>exception. Instead that message is logged (at INFO level), and
the pack attempt simply returns then (no pack is performed).</p>
</div>
<div class="section" id="id17">
<h2><a name="id17">ZEO</a></h2>
<p>Fixed a bug that prevented the -m / --monitor argument from working.</p>
</div>
<div class="section" id="zdaemon">
<h2><a name="zdaemon">zdaemon</a></h2>
<p>Added a -m / --mask option that controls the umask of the subprocess.</p>
</div>
<div class="section" id="zlog">
<h2><a name="zlog">zLOG</a></h2>
<p>The zLOG backend has been removed. zLOG is now just a facade over the
standard Python logging package. Environment variables like
STUPID_LOG_FILE are no longer honored. To configure logging, you need
to follow the directions in the logging package documentation. The
process is currently more complicated than configured zLOG. See
test.py for an example.</p>
</div>
<div class="section" id="zconfig">
<h2><a name="zconfig">ZConfig</a></h2>
<p>This release of ZODB contains ZConfig 2.1.</p>
<p>More documentation has been written.</p>
<p>Make sure keys specified as attributes of the <default> element are
converted by the appropriate key type, and are re-checked for derived
sections.</p>
<p>Refactored the ZConfig.components.logger schema components so that a
schema can import just one of the "eventlog" or "logger" sections if
desired. This can be helpful to avoid naming conflicts.</p>
<p>Added a reopen() method to the logger factories.</p>
<p>Always use an absolute pathname when opening a FileHandler.</p>
</div>
<div class="section" id="miscellaneous">
<h2><a name="miscellaneous">Miscellaneous</a></h2>
<p>The layout of the ZODB source release has changed. All the source
code is contained in a src subdirectory. The primary motivation for
this change was to avoid confusion caused by installing ZODB and then
testing it interactively from the source directory; the interpreter
would find the uncompiled ZODB package in the source directory and
report an import error.</p>
<p>A reference-counting bug was fixed, in the logic calling a modified
persistent object's data manager's register() method. The primary symptom
was rare assertion failures in Python's cyclic garbage collection.</p>
<p>The Connection class's onCommitAction() method was removed.</p>
<p>Some of the doc strings in ZODB are now written for processing by
epydoc.</p>
<p>Several new test suites were written using doctest instead of the
standard unittest TestCase framework.</p>
<p>MappingStorage now implements getTid().</p>
<p>ThreadedAsync: Provide a way to shutdown the servers using an exit
status.</p>
<p>The mkzeoinstance script looks for a ZODB installation, not a Zope
installation. The received wisdom is that running a ZEO server
without access to the appserver code avoids many mysterious problems.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-alpha-2">
<h1><a name="what-s-new-in-zodb3-3-3-alpha-2">What's new in ZODB3 3.3 alpha 2</a></h1>
<p>Release date: 06-Jan-2004</p>
<p>This release contains a major overhaul of the persistence machinery,
including some user-visible changes. The Persistent base class is now
a new-style class instead of an ExtensionClass. The change enables
the use of features like properties with persistent object classes.
The Persistent base class is now contained in the persistent package.</p>
<p>The Persistence package is included for backwards compatibility. The
Persistence package is used by Zope to provide special
ExtensionClass-compatibility features like a non-C3 MRO and an __of__
method. ExtensionClass is not included with this release of ZODB3.
If you use the Persistence package, it will print a warning and import
Persistent from persistent.</p>
<p>In short, the new persistent package is recommended for non-Zope
applications. The following dotted class names are now preferred over
earlier names:</p>
<ul class="simple">
<li>persistent.Persistent</li>
<li>persistent.list.PersistentList</li>
<li>persistent.mapping.PersistentMapping</li>
<li>persistent.TimeStamp</li>
</ul>
<p>The in-memory, per-connection object cache (pickle cache) was changed
to participate in garbage collection. This should reduce the number
of memory leaks, although we are still tracking a few problems.</p>
<div class="section" id="multi-version-concurrency-control">
<h2><a name="multi-version-concurrency-control">Multi-version concurrency control</a></h2>
<p>ZODB now supports multi-version concurrency control (MVCC) for
storages that support multiple revisions. FileStorage and
BDBFullStorage both support MVCC. In short, MVCC means that read
conflicts should almost never occur. When an object is modified in
one transaction, other concurrent transactions read old revisions of
the object to preserve consistency. In earlier versions of ZODB, any
access of the modified object would raise a ReadConflictError.</p>
<p>The ZODB internals changed significantly to accommodate MVCC. There
are relatively few user visible changes, aside from the lack of read
conflicts. It is possible to disable the MVCC feature using the mvcc
keyword argument to the DB open() method, ex.: db.open(mvcc=False).</p>
</div>
<div class="section" id="id18">
<h2><a name="id18">ZEO</a></h2>
<p>Changed the ZEO server and control process to work with a single
configuration file; this is now the default way to configure these
processes. (It's still possible to use separate configuration files.)
The ZEO configuration file can now include a "runner" section used by
the control process and ignored by the ZEO server process itself. If
present, the control process can use the same configuration file.</p>
<p>Fixed a performance problem in the logging code for the ZEO protocol.
The logging code could call repr() on arbitrarily long lists, even
though it only logged the first 60 bytes; worse, it called repr() even
if logging was currently disabled. Fixed to call repr() on individual
elements until the limit is reached.</p>
<p>Fixed a bug in zrpc (when using authentication) where the MAC header
wasn't being read for large messages, generating errors while unpickling
commands sent over the wire. Also fixed the zeopasswd.py script, added
testcases and provided a more complete commandline interface.</p>
<p>Fixed a misuse of the _map variable in zrpc Connectio objects, which
are also asyncore.dispatcher objects. This allows ZEO to work with
CVS Python (2.4). _map is used to indicate whether the dispatcher
users the default socket_map or a custom socket_map. A recent change
to asyncore caused it to use _map in its add_channel() and
del_channel() methods, which presumes to be a bug fix (may get ported
to 2.3). That causes our dubious use of _map to be a problem, because
we also put the Connections in the global socket_map. The new
asyncore won't remove it from the global socket map, because it has a
custom _map.</p>
<p>The prefix used for log messages from runzeo.py was changed from
RUNSVR to RUNZEO.</p>
</div>
<div class="section" id="id19">
<h2><a name="id19">Miscellaneous</a></h2>
<p>ReadConflictError objects now have an ignore() method. Normally, a
transaction that causes a read conflict can't be committed. If the
exception is caught and its ignore() method called, the transaction
can be committed. Application code may need this in advanced
applications.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-3-alpha-1">
<h1><a name="what-s-new-in-zodb3-3-3-alpha-1">What's new in ZODB3 3.3 alpha 1</a></h1>
<p>Release date: 17-Jul-2003</p>
<div class="section" id="new-features-of-persistence">
<h2><a name="new-features-of-persistence">New features of Persistence</a></h2>
<p>The Persistent base class is a regular Python type implemented in C.
It should be possible to create new-style classes that inherit from
Persistent, and, thus, use all the new Python features introduced in
Python 2.2 and 2.3.</p>
<p>The __changed__() method on Persistent objects is no longer supported.</p>
</div>
<div class="section" id="new-features-in-btrees">
<h2><a name="new-features-in-btrees">New features in BTrees</a></h2>
<p>BTree, Bucket, TreeSet and Set objects are now iterable objects, playing
nicely with the iteration protocol introduced in Python 2.2, and can
be used in any context that accepts an iterable object. As for Python
dicts, the iterator constructed for BTrees and Buckets iterates
over the keys.</p>
<pre class="doctest-block">
>>> from BTrees.OOBTree import OOBTree
>>> b = OOBTree({"one": 1, "two": 2, "three": 3, "four": 4})
>>> for key in b: # iterates over the keys
... print key
four
one
three
two
>>> list(enumerate(b))
[(0, 'four'), (1, 'one'), (2, 'three'), (3, 'two')]
>>> i = iter(b)
>>> i.next()
'four'
>>> i.next()
'one'
>>> i.next()
'three'
>>> i.next()
'two'
>>>
</pre>
<p>As for Python dicts in 2.2, BTree and Bucket objects have new
.iterkeys(), .iteritems(), and .itervalues() methods. TreeSet and Set
objects have a new .iterkeys() method. Unlike as for Python dicts,
these new methods accept optional min and max arguments to effect
range searches. While Bucket.keys() produces a list, Bucket.iterkeys()
produces an iterator, and similarly for Bucket values() versus
itervalues(), Bucket items() versus iteritems(), and Set keys() versus
iterkeys(). The iter{keys,values,items} methods of BTrees and the
iterkeys() method of Treesets also produce iterators, while their
keys() (etc) methods continue to produce BTreeItems objects (a form of
"lazy" iterator that predates Python 2.2's iteration protocol).</p>
<pre class="doctest-block">
>>> sum(b.itervalues())
10
>>> zip(b.itervalues(), b.iterkeys())
[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]
>>>
</pre>
<p>BTree, Bucket, TreeSet and Set objects also implement the __contains__
method new in Python 2.2, which means that testing for key membership
can be done directly now via the "in" and "not in" operators:</p>
<pre class="doctest-block">
>>> "won" in b
False
>>> "won" not in b
True
>>> "one" in b
True
>>>
</pre>
<p>All old and new range-search methods now accept keyword arguments,
and new optional excludemin and excludemax keyword arguments. The
new keyword arguments allow doing a range search that's exclusive
at one or both ends (doesn't include min, and/or doesn't include
max).</p>
<pre class="doctest-block">
>>> list(b.keys())
['four', 'one', 'three', 'two']
>>> list(b.keys(max='three'))
['four', 'one', 'three']
>>> list(b.keys(max='three', excludemax=True))
['four', 'one']
>>>
</pre>
</div>
<div class="section" id="other-improvements">
<h2><a name="other-improvements">Other improvements</a></h2>
<p>The exceptions generated by write conflicts now contain the name of
the conflicted object's class. This feature requires support for the
storage. All the standard storages support it.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-2">
<h1><a name="what-s-new-in-zodb3-3-2">What's new in ZODB3 3.2</a></h1>
<p>Release date: 08-Oct-2003</p>
<p>Nothing has changed since release candidate 1.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-2-release-candidate-1">
<h1><a name="what-s-new-in-zodb3-3-2-release-candidate-1">What's new in ZODB3 3.2 release candidate 1</a></h1>
<p>Release date: 01-Oct-2003</p>
<p>Added a summary to the Doc directory. There are several new documents
in the 3.2 release, including "Using zdctl and zdrun to manage server
processes" and "Running a ZEO Server HOWTO."</p>
<p>Fixed ZEO's protocol negotiation mechanism so that a client ZODB 3.1
can talk to a ZODB 3.2 server.</p>
<p>Fixed a memory leak in the ZEO server. The server was leaking a few
KB of memory per connection.</p>
<p>Fixed a memory leak in the ZODB object cache (cPickleCache). The
cache did not release two references to its Connection, causing a
large cycle of objects to leak when a database was closed.</p>
<p>Fixed a bug in the ZEO code that caused it to leak socket objects on
Windows. Specifically, fix the trigger mechanism so that both sockets
created for a trigger are closed.</p>
<p>Fixed a bug in the ZEO storage server that caused it to leave temp
files behind. The CommitLog class contains a temp file, but it was
not closing the file.</p>
<p>Changed the order of setuid() and setgid() calls in zdrun, so that
setgid() is called first.</p>
<p>Added a timeout to the ZEO test suite that prevents hangs. The test
suite creates ZEO servers with randomly assigned ports. If the port
happens to be in use, the test suite would hang because the ZEO client
would never stop trying to connect. The fix will cause the test to
fail after a minute, but should prevent the test runner from hanging.</p>
<p>The logging package was updated to include the latest version of the
logging package from Python CVS. Note that this package is only
installed for Python 2.2. In later versions of Python, it is
available in the Python standard library.</p>
<p>The ZEO1 directory was removed from the source distribution. ZEO1 is
not supported, and we never intended to include it in the release.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-2-beta-3">
<h1><a name="what-s-new-in-zodb3-3-2-beta-3">What's new in ZODB3 3.2 beta 3</a></h1>
<p>Release date: 23-Sep-2003</p>
<p>Note: The changes listed for this release include changes also made in
ZODB 3.1.x releases and ported to the 3.2 release.</p>
<p>This version of ZODB 3.2 is not compatible with Python 2.1. Early
versions were explicitly designed to be compatible with Zope 2.6.
That plan has been dropped, because Zope 2.7 is already in beta
release.</p>
<p>Several of the classes in ZEO and ZODB now inherit from object, making
them new-style classes. The primary motivation for the change was to
make it easier to debug memory leaks. We don't expect any behavior to
change as a result.</p>
<p>A new feature to allow removal of connection pools for versions was
ported from Zope 2.6. This feature is needed by Zope to avoid denial
of service attacks that allow a client to create an arbitrary number
of version pools.</p>
<p>Fixed several critical ZEO bugs.</p>
<ul class="simple">
<li>If several client transactions were blocked waiting for the storage
and one of the blocked clients disconnected, the server would
attempt to restart one of the other waiting clients. Since the
disconnected client did not have the storage lock, this could lead
to deadlock. It could also cause the assertion "self._client is
None" to fail.</li>
<li>If a storage server fails or times out between the vote and the
finish, the ZEO cache could get populated with objects that didn't
make it to the storage server.</li>
<li>If a client loses its connection to the server near the end of a
transaction, it is now guaranteed to get a ClientDisconnected error
even if it reconnects before the transaction finishes. This is
necessary because the server will always abort the transaction.
In some cases, the client would never see an error for the aborted
transaction.</li>
<li>In tpc_finish(), reordered the calls so that the server's tpc_finish()
is called (and must succeed) before we update the ZEO client cache.</li>
<li>The storage name is now prepended to the sort key, to ensure a
unique global sort order if storages are named uniquely. This
can prevent deadlock in some unusual cases.</li>
</ul>
<p>Fixed several serious flaws in the implementation of the ZEO
authentication protocol.</p>
<ul class="simple">
<li>The smac layer would accept a message without a MAC even after the
session key was established.</li>
<li>The client never initialized its session key, so it never checked
incoming messages or created MACs for outgoing messags.</li>
<li>The smac layer used a single HMAC instance for sending and receiving
messages. This approach could only work if client and server were
guaranteed to process all messages in the same total order, which
could only happen in simple scenarios like unit tests.</li>
</ul>
<p>Fixed a bug in ExtensionClass when comparing ExtensionClass instances.
The code could raise RuntimeWarning under Python 2.3, and produce
incorrect results on 64-bit platforms.</p>
<p>Fixed bug in BDBStorage that could lead to DBRunRecoveryErrors when a
transaction was aborted after performing operations like commit
version or undo that create new references to existing pickles.</p>
<p>Fixed a bug in Connection.py that caused it to fail with an
AttributeError if close() was called after the database was closed.</p>
<p>The test suite leaves fewer log files behind, although it still leaves
a lot of junk. The test.py script puts each tests temp files in a
separate directory, so it is easier to see which tests are causing
problems. Unfortunately, it is still to tedious to figure out why the
identified tests are leaving files behind.</p>
<p>This release contains the latest and greatest version of the
BDBStorage. This storage has still not seen testing in a production
environment, but it represents the current best design and most recent
code culled from various branches where development has occurred.</p>
<p>The Tools directory contains a number of small improvements, a few new
tools, and README.txt that catalogs the tools. Many of the tools are
installed by setup.py; those scripts will now have a #! line set
automatically on Unix.</p>
<p>Fixed bugs in Tools/repozo.py, including a timing-dependent one that
could cause the following invocation of repozo to do a full backup when
an incremental backup would have sufficed.</p>
<p>A pair of new scripts from Jim Fulton can be used to synthesize
workloads and measure ZEO performance: see zodbload.py and
zeoserverlog.py in the Tools directory. Note that these require
Zope.</p>
<p>Tools/checkbtrees.py was strengthened in two ways:</p>
<ul class="simple">
<li>In addition to running the _check() method on each BTree B found,
BTrees.check.check(B) is also run. The check() function was written
after checkbtrees.py, and identifies kinds of damage B._check()
cannot find.</li>
<li>Cycles in the object graph no longer lead to unbounded output.
Note that preventing this requires remembering the oid of each
persistent object found, which increases the memory needed by the
script.</li>
</ul>
</div>
<div class="section" id="what-s-new-in-zodb3-3-2-beta-2">
<h1><a name="what-s-new-in-zodb3-3-2-beta-2">What's new in ZODB3 3.2 beta 2</a></h1>
<p>Release date: 16-Jun-2003</p>
<p>Fixed critical race conditions in ZEO's cache consistency code that
could cause invalidations to be lost or stale data to be written to
the cache. These bugs can lead to data loss or data corruption.
These bugs are relatively unlikely to be provoked in sites with few
conflicts, but the possibility of failure existed any time an object
was loaded and stored concurrently.</p>
<p>Fixed 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.)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Two new features snuck into this beta release.</p>
<p>The ZODB.transact module provides a helper function that converts a
regular function or method into a transactional one.</p>
<p>The ZEO client cache now supports Adaptable Persistence (APE). The
cache used to expect that all OIDs were eight bytes long.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-2-beta-1">
<h1><a name="what-s-new-in-zodb3-3-2-beta-1">What's new in ZODB3 3.2 beta 1</a></h1>
<p>Release date: 30-May-2003</p>
<div class="section" id="id20">
<h2><a name="id20">ZODB</a></h2>
<p>Invalidations are now 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.</p>
<p>A number of minor reference count fixes in the object cache were
fixed. That's the cPickleCache.c file.</p>
<p>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.</p>
<p>The "other" argument to copyTransactionsFrom() only needs to have an
.iterator() method. For convenience, change FileStorage's and
BDBFullStorage's iterator to have this method, which just returns
self.</p>
<p>Mount points are now visible from mounted objects.</p>
<p>Fixed memory leak involving database connections and caches. When a
connection or database was closed, the cache and database leaked,
because of a circular reference involving the cache. Fixed the cache
to explicitly clear out its contents when its connection is closed.</p>
<p>The ZODB cache has fewer methods. It used to expose methods that
could mutate the dictionary, which allowed users to violate internal
invariants.</p>
</div>
<div class="section" id="id21">
<h2><a name="id21">ZConfig</a></h2>
<p>It is now possible to configure ZODB databases and storages and ZEO
servers using ZConfig.</p>
</div>
<div class="section" id="zeo-zdaemon">
<h2><a name="zeo-zdaemon">ZEO & zdaemon</a></h2>
<p>ZEO now supports authenticated client connections. The default
authentication protocol uses a hash-based challenge-response protocol
to prove identity and establish a session key for message
authentication. The architecture is pluggable to allow third-parties
to developer better authentication protocols.</p>
<p>There is a new HOWTO for running a ZEO server. The draft in this
release is incomplete, but provides more guidance than previous
releases. See the file Doc/ZEO/howto.txt.</p>
<p>The ZEO storage server's transaction timeout feature was refactored
and made slightly more rebust.</p>
<p>A new ZEO utility script, ZEO/mkzeoinst.py, was added. This creates a
standard directory structure and writes a configuration file with
mostly default values, and a bootstrap script that can be used to
manage and monitor the server using zdctl.py (see below).</p>
<p>Much work was done to improve zdaemon's zdctl.py and zdrun.py scripts.
(In the alpha 1 release, zdrun.py was called zdaemon.py, but
installing it in <prefix>/bin caused much breakage due to the name
conflict with the zdaemon package.) Together with the new
mkzeoinst.py script, this makes controlling a ZEO server a breeze.</p>
<p>A ZEO client will not read from its cache during cache verification.
This fix was necessary to prevent the client from reading inconsistent
data.</p>
<p>The isReadOnly() method of a ZEO client was fixed to return the false
when the client is connected to a read-only fallback server.</p>
<p>The sync() method of ClientStorage and the pending() method of a zrpc
connection now do both input and output.</p>
<p>The short_repr() function used to generate log messages was fixed so
that it does not blow up creating a repr of very long tuples.</p>
</div>
<div class="section" id="id22">
<h2><a name="id22">Storages</a></h2>
<p>FileStorage has a new pack() implementation that fixes several
reported problems that could lead to data loss.</p>
<p>Two small bugs were fixed in DemoStorage. undoLog() did not handle
its arguments correctly and pack() could accidentally delete objects
created in versions.</p>
<p>Fixed trivial bug in fsrecover that prevented it from working at all.</p>
<p>FileStorage will use fsync() on Windows starting with Python 2.2.3.</p>
<p>FileStorage's commit version was fixed. It used to stop after the
first object, leaving all the other objects in the version.</p>
</div>
<div class="section" id="id23">
<h2><a name="id23">BTrees</a></h2>
<p>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</p>
<blockquote>
b[obj] = "I'm a string, not an integer"</blockquote>
<p>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").</p>
<p>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).</p>
<p>Other minor BTree leak scenarios were also fixed.</p>
</div>
<div class="section" id="id24">
<h2><a name="id24">Tools</a></h2>
<p>New tool zeoqueue.py for parsing ZEO log files, looking for blocked
transactions.</p>
<p>New tool repozo.py (originally by Anthony Baxter) for performing
incremental backups of Data.fs files.</p>
<p>The fsrecover.py script now does a better job of recovering from
errors the occur in the middle of a transaction record. Fixed several
bugs that caused partial or total failures in earlier versions.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-2-alpha-1">
<h1><a name="what-s-new-in-zodb3-3-2-alpha-1">What's new in ZODB3 3.2 alpha 1</a></h1>
<p>Release date: 17-Jan-2003</p>
<p>Most of the changes in this release are performance and stability
improvements to ZEO. A major packaging change is that there won't be
a separate ZEO release. The new ZConfig is a noteworthy addtion (see
below).</p>
<div class="section" id="id25">
<h2><a name="id25">ZODB</a></h2>
<p>An experimental new transaction API was added. The Connection class
has a new method, setLocalTransaction(). ZODB applications can call
this method to bind transactions to connections rather than threads.
This is especially useful for GUI applications, which often have only
one thread but multiple independent activities within that thread
(generally one per window). Thanks to Christian Reis for championing
this feature.</p>
<p>Applications that take advantage of this feature should not use the
get_transaction() function. Until now, ZODB itself sometimes assumed
get_transaction() was the only way to get the transaction. Minor
corrections have been added. The ZODB test suite, on the other hand,
can continue to use get_transaction(), since it is free to assume that
transactions are bound to threads.</p>
</div>
<div class="section" id="id26">
<h2><a name="id26">ZEO</a></h2>
<p>There is a new recommended script for starting a storage server. We
recommend using ZEO/runzeo.py instead of ZEO/start.py. The start.py
script is still available in this release, but it will no longer be
maintained and will eventually be removed.</p>
<p>There is a new zdaemon implementation. This version is a separate
script that runs an arbitrary daemon. To run the ZEO server as a
daemon, you would run "zdrun.py runzeo.py". There is also a simple
shell, zdctl.py, that can be used to manage a daemon. Try
"zdctl.py -p runzeo.py".</p>
<p>There is a new version of the ZEO protocol in this release and a first
stab at protocol negotiation. (It's a first stab because the protocol
checking supporting in ZODB 3.1 was too primitive to support anything
better.) A ZODB 3.2 ZEO client can talk to an old server, but a ZODB
3.2 server can't talk to an old client. It's safe to upgrade all the
clients first and upgrade the server last. The ZEO client cache
format changed, so you'll need to delete persistent caches before
restarting clients.</p>
<p>The ZEO cache verification protocol was revised to require many fewer
messages in cases where a client or server restarts quickly.</p>
<p>The performance of full cache verification has improved dramatically.
Measurements from Jim were somewhere in 2x-5x. The
implementation was fixed to use the very-fast getSerial() method on
the storage instead of the comparatively slow load().</p>
<p>The ZEO server has an optional timeout feature that will abort a
connection that does not commit within a certain amount of time. The
timeout works by closing the socket the client is using, causing both
client and server to abort the transaction and continue. This is a
drastic step, but can be useful to prevent a hung client or other bug
from blocking a server indefinitely.</p>
<p>A bug was fixed in the ZEO protocol that allowed clients to read stale
cache data while cache verification was being performed. The fixed
version prevents the client from using the storage until after
verification completes.</p>
<p>The ZEO server has an experimental monitoring interface that reports
usage statistics for the storage server including number of connected
clients and number of transactions active and committed. It can be
enabled by passing the -m flag to runsvr.py.</p>
<p>The ZEO ClientStorage no longer supports the environment variables
CLIENT_HOME, INSTANCE_HOME, or ZEO_CLIENT.</p>
<p>The ZEO1 package is still included with this release, but there is no
longer an option to install it.</p>
</div>
<div class="section" id="id27">
<h2><a name="id27">BTrees</a></h2>
<p>The BTrees package now has a check module that inspects a BTree to
check internal invariants. Bugs in older versions of the code code
leave a BTree in an inconsistent state. Calling BTrees.check.check()
on a BTree object should verify its consistency. (See the NEWS
section for 3.1 beta 1 below to for the old BTrees bugs.)</p>
<p>Fixed a rare conflict resolution problem in the BTrees that could
cause an segfault when the conflict resolution resulted in any
empty bucket.</p>
</div>
<div class="section" id="installation">
<h2><a name="installation">Installation</a></h2>
<p>The distutils setup now installs several Python scripts. The
runzeo.py and zdrun.py scripts mentioned above and several fsXXX.py
scripts from the Tools directory.</p>
<p>The test.py script does not run all the ZEO tests by default, because
the ZEO tests take a long time to run. Use --all to run all the
tests. Otherwise a subset of the tests, mostly using MappingStorage,
are run.</p>
</div>
<div class="section" id="id28">
<h2><a name="id28">Storages</a></h2>
<p>There are two new storages based on Sleepycat's BerkeleyDB in the
BDBStorage package. Barry will have to write more here, because I
don't know how different they are from the old bsddb3Storage
storages. See Doc/BDBStorage.txt for more information.</p>
<p>It now takes less time to open an existing FileStorage. The
FileStorage uses a BTree-based index that is faster to pickle and
unpickle. It also saves the index periodically so that subsequent
opens will go fast even if the storage was not closed cleanly.</p>
</div>
<div class="section" id="misc">
<h2><a name="misc">Misc</a></h2>
<p>The new ZConfig package, which will be used by Zope and ZODB, is
included. ZConfig provides a configuration syntax, similar to
Apache's syntax. The package can be used to configure the ZEO server
and ZODB databases. See the module ZODB.config for functions to open
the database from configuration. See ZConfig/doc for more info.</p>
<p>The zLOG package now uses the logging package by Vinay Sajip, which
will be included in Python 2.3.</p>
<p>The Sync extension was removed from ExtensionClass, because it was not
used by ZODB.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-4">
<h1><a name="what-s-new-in-zodb3-3-1-4">What's new in ZODB3 3.1.4?</a></h1>
<p>Release date: 11-Sep-2003</p>
<p>A new feature to allow removal of connection pools for versions was
ported from Zope 2.6. This feature is needed by Zope to avoid denial
of service attacks that allow a client to create an arbitrary number
of version pools.</p>
<p>A pair of new scripts from Jim Fulton can be used to synthesize
workloads and measure ZEO performance: see zodbload.py and
zeoserverlog.py in the Tools directory. Note that these require
Zope.</p>
<p>Tools/checkbtrees.py was strengthened in two ways:</p>
<ul class="simple">
<li>In addition to running the _check() method on each BTree B found,
BTrees.check.check(B) is also run. The check() function was written
after checkbtrees.py, and identifies kinds of damage B._check()
cannot find.</li>
<li>Cycles in the object graph no longer lead to unbounded output.
Note that preventing this requires remembering the oid of each
persistent object found, which increases the memory needed by the
script.</li>
</ul>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-3">
<h1><a name="what-s-new-in-zodb3-3-1-3">What's new in ZODB3 3.1.3?</a></h1>
<p>Release date: 18-Aug-2003</p>
<p>Fixed several critical ZEO bugs.</p>
<ul class="simple">
<li>If a storage server fails or times out between the vote and the
finish, the ZEO cache could get populated with objects that didn't
make it to the storage server.</li>
<li>If a client loses its connection to the server near the end of a
transaction, it is now guaranteed to get a ClientDisconnected error
even if it reconnects before the transaction finishes. This is
necessary because the server will always abort the transaction.
In some cases, the client would never see an error for the aborted
transaction.</li>
<li>In tpc_finish(), reordered the calls so that the server's tpc_finish()
is called (and must succeed) before we update the ZEO client cache.</li>
<li>The storage name is now prepended to the sort key, to ensure a
unique global sort order if storages are named uniquely. This
can prevent deadlock in some unusual cases.</li>
</ul>
<p>A variety of fixes and improvements to Berkeley storage (aka BDBStorage)
were back-ported from ZODB 4. This release now contains the most
current version of the Berkeley storage code. Many tests have been
back-ported, but not all.</p>
<p>Modified the Windows tests to wait longer at the end of ZEO tests for
the server to shut down. Before Python 2.3, there is no waitpid() on
Windows, and, thus, no way to know if the server has shut down. The
change makes the Windows ZEO tests much less likely to fail or hang,
at the cost of increasing the time needed to run the tests.</p>
<p>Fixed a bug in ExtensionClass when comparing ExtensionClass instances.
The code could raise RuntimeWarning under Python 2.3, and produce
incorrect results on 64-bit platforms.</p>
<p>Fixed bugs in Tools/repozo.py, including a timing-dependent one that
could cause the following invocation of repozo to do a full backup when
an incremental backup would have sufficed.</p>
<p>Added Tools/README.txt that explains what each of the scripts in the
Tools directory does.</p>
<p>There were many small changes and improvements to the test suite.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-2-final">
<h1><a name="what-s-new-in-zodb3-3-1-2-final">What's new in ZODB3 3.1.2 final?</a></h1>
<p>Fixed bug in FileStorage pack that caused it to fail if it encountered
an old undo record (status "u").</p>
<p>Fixed several bugs in FileStorage pack that could cause OverflowErrors
for storages > 2 GB.</p>
<p>Fixed memory leak in TimeStamp.laterThan() that only occurred when it
had to create a new TimeStamp.</p>
<p>Fixed two BTree bugs that were fixed on the head a while ago:</p>
<blockquote>
<ul class="simple">
<li>bug in fsBTree that would cause byValue searches to end early.
(fsBTrees are never used this way, but it was still a bug.)</li>
<li>bug that lead to segfault if BTree was mutated via deletion
while it was being iterated over.</li>
</ul>
</blockquote>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-2-beta-2">
<h1><a name="what-s-new-in-zodb3-3-1-2-beta-2">What's new in ZODB3 3.1.2 beta 2?</a></h1>
<p>Fixed critical race conditions in ZEO's cache consistency code that
could cause invalidations to be lost or stale data to be written to
the cache. These bugs can lead to data loss or data corruption.
These bugs are relatively unlikely to be provoked in sites with few
conflicts, but the possibility of failure existed any time an object
was loaded and stored concurrently.</p>
<p>Fixed 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.)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-2-beta-1">
<h1><a name="what-s-new-in-zodb3-3-1-2-beta-1">What's new in ZODB3 3.1.2 beta 1?</a></h1>
<div class="section" id="id29">
<h2><a name="id29">ZODB</a></h2>
<p>Invalidations are now 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.</p>
<p>A number of minor reference count fixes in the object cache were
fixed. That's the cPickleCache.c file.</p>
<p>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.</p>
</div>
<div class="section" id="id30">
<h2><a name="id30">ZEO</a></h2>
<p>A ZEO client will not read from its cache during cache verification.
This fix was necessary to prevent the client from reading inconsistent
data.</p>
<p>The isReadOnly() method of a ZEO client was fixed to return the false
when the client is connected to a read-only fallback server.</p>
<p>The sync() method of ClientStorage and the pending() method of a zrpc
connection now do both input and output.</p>
<p>The short_repr() function used to generate log messages was fixed so
that it does not blow up creating a repr of very long tuples.</p>
</div>
<div class="section" id="id31">
<h2><a name="id31">Storages</a></h2>
<p>FileStorage has a new pack() implementation that fixes several
reported problems that could lead to data loss.</p>
<p>Two small bugs were fixed in DemoStorage. undoLog() did not handle
its arguments correctly and pack() could accidentally delete objects
created in versions.</p>
<p>Fixed trivial bug in fsrecover that prevented it from working at all.</p>
<p>FileStorage will use fsync() on Windows starting with Python 2.2.3.</p>
<p>FileStorage's commit version was fixed. It used to stop after the
first object, leaving all the other objects in the version.</p>
</div>
<div class="section" id="id32">
<h2><a name="id32">BTrees</a></h2>
<p>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</p>
<blockquote>
b[obj] = "I'm a string, not an integer"</blockquote>
<p>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").</p>
<p>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).</p>
<p>Other minor BTree leak scenarios were also fixed.</p>
</div>
<div class="section" id="other">
<h2><a name="other">Other</a></h2>
<p>Comparing a Missing.Value object to a C type that provide its own
comparison operation could lead to a segfault when the Missing.Value
was on the right-hand side of the comparison operator. The Missing
class was fixed so that its coercion and comparison operations are
safe.</p>
</div>
<div class="section" id="id33">
<h2><a name="id33">Tools</a></h2>
<p>Four tools are now installed by setup.py: fsdump.py, fstest.py,
repozo.py, and zeopack.py.</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-1-final">
<h1><a name="what-s-new-in-zodb3-3-1-1-final">What's new in ZODB3 3.1.1 final?</a></h1>
<p>Release date: 11-Feb-2003</p>
<div class="section" id="id34">
<h2><a name="id34">Tools</a></h2>
<p>Updated repozo.py tool</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-1-beta-2">
<h1><a name="what-s-new-in-zodb3-3-1-1-beta-2">What's new in ZODB3 3.1.1 beta 2?</a></h1>
<p>Release date: 03-Feb-2003</p>
<p>The Transaction "hosed" feature is disabled in this release. If a
transaction fails during the tpc_finish() it is not possible, in
general, to know whether the storage is in a consistent state. For
example, a ZEO server may commit the data and then fail before sending
confirmation of the commit to the client. If multiple storages are
involved in a transaction, the problem is exacerbated: One storage may
commit the data while another fails to commit. In previous versions
of ZODB, the database would set a global "hosed" flag that prevented
any other transaction from committing until an administrator could
check the status of the various failed storages and ensure that the
database is in a consistent state. This approach favors data
consistency over availability. The new approach is to log a panic but
continue. In practice, availability seems to be more important than
consistency. The failure mode is exceedingly rare in either case.</p>
<p>The BTrees-based fsIndex for FileStorage is enabled. This version of
the index is faster to load and store via pickle and uses less memory
to store keys. We had intended to enable this feature in an earlier
release, but failed to actually do it; thus, it's getting enabled as a
bug fix now.</p>
<p>Two rare bugs were fixed in BTrees conflict resolution. The most
probable symptom of the bug would have been a segfault. The bugs
were found via synthetic stress tests rather than bug reports.</p>
<p>A value-based consistency checker for BTrees was added. See the
module BTrees.check for the checker and other utilities for working
with BTrees.</p>
<p>A new script called repozo.py was added. This script, originally
written by Anthony Baxter, provides an incremental backup scheme for
FileStorage based storages.</p>
<p>zeopack.py has been fixed to use a read-only connection.</p>
<p>Various small autopack-related race conditions have been fixed in the
Berkeley storage implementations. There have been some table changes
to the Berkeley storages so any storage you created in 3.1.1b1 may not
work. Part of these changes was to add a storage version number to
the schema so these types of incompatible changes can be avoided in
the future.</p>
<p>Removed the chance of bogus warnings in the FileStorage iterator.</p>
<div class="section" id="id35">
<h2><a name="id35">ZEO</a></h2>
<p>The ZEO version number was bumped to 2.0.2 on account of the following
minor feature additions.</p>
<p>The performance of full cache verification has improved dramatically.
Measurements from Jim were somewhere in 2x-5x. The
implementation was fixed to use the very-fast getSerial() method on
the storage instead of the comparatively slow load().</p>
<p>The ZEO server has an optional timeout feature that will abort a
connection that does not commit within a certain amount of time. The
timeout works by closing the socket the client is using, causing both
client and server to abort the transaction and continue. This is a
drastic step, but can be useful to prevent a hung client or other bug
from blocking a server indefinitely.</p>
<p>If a client was disconnected during a transaction, the tpc_abort()
call did not properly reset the internal state about the transaction.
The bug caused the next transaction to fail in its tpc_finish().
Also, any ClientDisconnected exceptions raised during tpc_abort() are
ignored.</p>
<p>ZEO logging has been improved by adding more logging for important
events, and changing the logging level for existing messages to a more
appropriate level (usually lower).</p>
</div>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-1-beta-1">
<h1><a name="what-s-new-in-zodb3-3-1-1-beta-1">What's new in ZODB3 3.1.1 beta 1?</a></h1>
<p>Release date: 10-Dev-2002</p>
<p>It was possible for earlier versions of ZODB to deadlock when using
multiple storages. If multiple transactions committed concurrently
and both transactions involved two or more shared storages, deadlock
was possible. This problem has been fixed by introducing a sortKey()
method to the transaction and storage APIs that is used to define an
ordering on transaction participants. This solution will prevent
deadlocks provided that all transaction participants that use locks
define a valid sortKey() method. A warning is raised if a participant
does not define sortKey(). For backwards compatibility, BaseStorage
provides a sortKey() that uses __name__.</p>
<p>Added code to ThreadedAsync/LoopCallback.py to work around a bug in
asyncore.py: a handled signal can cause unwanted reads to happen.</p>
<p>A bug in FileStorage related to object uncreation was fixed. If an
a transaction that created an object was undone, FileStorage could
write a bogus data record header that could lead to strange errors if
the object was loaded. An attempt to load an uncreated object now
raises KeyError, as expected.</p>
<p>The restore() implementation in FileStorage wrote incorrect
backpointers for a few corner cases involving versions and undo. It
also failed if the backpointer pointed to a record that was before the
pack time. These specific bugs have been fixed and new test cases
were added to cover them.</p>
<p>A bug was fixed in conflict resolution that raised a NameError when a
class involved in a conflict could not be loaded. The bug did not
affect correctness, but prevent ZODB from caching the fact that the
class was unloadable. A related bug prevented spurious
AttributeErrors when a class could not be loaded. It was also fixed.</p>
<p>The script Tools/zeopack.py was fixed to work with ZEO 2. It was
untested and had two silly bugs.</p>
<p>Some C extensions included standard header files before including
Python.h, which is not allowed. They now include Python.h first,
which eliminates compiler warnings in certain configurations.</p>
<p>The BerkeleyDB based storages have been merged from the trunk,
providing a much more robust version of the storages. They are not
backwards compatible with the old storages, but the decision was made
to update them in this micro release because the old storages did not
work for all practical purposes. For details, see Doc/BDBStorage.txt.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-final">
<h1><a name="what-s-new-in-zodb3-3-1-final">What's new in ZODB3 3.1 final?</a></h1>
<p>Release date: 28-Oct-2002</p>
<p>If an error occurs during conflict resolution, the store will silently
catch the error, log it, and continue as if the conflict was
unresolvable. ZODB used to behave this way, and the change to catch
only ConflictError was causing problems in deployed systems. There
are a lot of legitimate errors that should be caught, but it's too
close to the final release to make the substantial changes needed to
correct this.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-beta-3">
<h1><a name="what-s-new-in-zodb3-3-1-beta-3">What's new in ZODB3 3.1 beta 3?</a></h1>
<p>Release date: 21-Oct-2002</p>
<p>A small extension was made to the iterator protocol. The Record
objects, which are returned by the per-transaction iterators, contain
a new <cite>data_txn</cite> attribute. It is None, unless the data contained in
the record is a logical copy of an earlier transaction's data. For
example, when transactional undo modifies an object, it creates a
logical copy of the earlier transaction's data. Note that this
provide a stronger statement about consistency than whether the data
in two records is the same; it's possible for two different updates to
an object to coincidentally have the same data.</p>
<p>The restore() method was extended to take the data_txn attribute
mentioned above as an argument. FileStorage uses the new argument to
write a backpointer if possible.</p>
<p>A few bugs were fixed.</p>
<p>The setattr slot of the cPersistence C API was being initialized to
NULL. The proper initialization was restored, preventing crashes in
some applications with C extensions that used persistence.</p>
<p>The return value of TimeStamp's __cmp__ method was clipped to return
only 1, 0, -1.</p>
<p>The restore() method was fixed to write a valid backpointer if the
update being restored is in a version.</p>
<p>Several bugs and improvements were made to zdaemon, which can be used
to run the ZEO server. The parent now forwards signals to the child
as intended. Pidfile handling was improved and the trailing newline
was omitted.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-beta-2">
<h1><a name="what-s-new-in-zodb3-3-1-beta-2">What's new in ZODB3 3.1 beta 2?</a></h1>
<p>Release date: 4-Oct-2002</p>
<p>A few bugs have been fixed, some that were found with the help of
Neal Norwitz's PyChecker.</p>
<p>The zeoup.py tool has been fixed to allow connecting to a read-only
storage, when the --nowrite option is given.</p>
<p>Casey Duncan fixed a few bugs in the recent changes to undoLog().</p>
<p>The fstest.py script no longer checks that each object modified in a
transaction has a serial number that matches the transaction id.
This invariant is no longer maintained; several new features in the
3.1 release depend on it.</p>
<p>The ZopeUndo package was added. If ZODB3 is being used to run a ZEO
server that will be used with Zope, it is usually best if the server
and the Zope client don't share any software. The Zope undo
framework, however, requires that a Prefix object be passed between
client and server. To support this use, ZopeUndo was created to hold
the Prefix object.</p>
<p>Many bugs were fixed in ZEO, and a couple of features added. See
<cite>ZEO-NEWS.txt</cite> for details.</p>
<p>The ZODB guide included in the Doc directory has been updated. It is
still incomplete, but most of the references to old ZODB packages have
been removed. There is a new section that briefly explains how to use
BTrees.</p>
<p>The zeoup.py tool connects using a read-only connection when --nowrite
is specifified. This feature is useful for checking on read-only ZEO
servers.</p>
</div>
<div class="section" id="what-s-new-in-zodb3-3-1-beta-1">
<h1><a name="what-s-new-in-zodb3-3-1-beta-1">What's new in ZODB3 3.1 beta 1?</a></h1>
<p>Release date: 12-Sep-2002</p>
<p>We've changed the name and version number of the project, but it's
still the same old ZODB. There have been a lot of changes since the
last release.</p>
<div class="section" id="new-zodb-cache">
<h2><a name="new-zodb-cache">New ZODB cache</a></h2>
<p>Toby Dickenson implemented a new Connection cache for ZODB. The cache
is responsible for pointer swizzling (translating between oids and
Python objects) and for keeping recently used objects in memory. The
new cache is a big improvement over the old cache. It strictly honors
its size limit, where size is specified in number of objects, and it
evicts objects in least recently used (LRU) order.</p>
<p>Users should take care when setting the cache size, which has a
default value of 400 objects. The old version of the cache often held
many more objects than its specified size. An application may not
perform as well with a small cache size, because the cache no longer
exceeds the limit.</p>
</div>
<div class="section" id="id36">
<h2><a name="id36">Storages</a></h2>
<p>The index used by FileStorage was reimplemented using a custom BTrees
object. The index maps oids to file offsets, and is kept in memory at
all times. The new index uses about 1/4 the memory of the old,
dictionary-based index. See the module ZODB.fsIndex for details.</p>
<p>A security flaw was corrected in transactionalUndo(). The transaction
ids returned by undoLog() and used for transactionalUndo() contained a
file offset. An attacker could construct a pickle with a bogus
transaction record in its binary data, deduce the position of the
pickle in the file from the undo log, then submit an undo with a bogus
file position that caused the pickle to get written as a regular data
record. The implementation was fixed so that file offsets are not
included in the transaction ids.</p>
<p>Several storages now have an explicit read-only mode. For example,
passing the keyword argument read_only=1 to FileStorage will make it
read-only. If a write operation is performed on a read-only storage,
a ReadOnlyError will be raised.</p>
<p>The storage API was extended with new methods that support the Zope
Replication Service (ZRS), a proprietary Zope Corp product. We expect
these methods to be generally useful. The methods are:</p>
<blockquote>
<ul>
<li><p class="first">restore(oid, serialno, data, version, transaction)</p>
<p>Perform a store without doing consistency checks. A client can
use this method to provide a new current revision of an object.
The <tt class="docutils literal"><span class="pre">serialno</span></tt> argument is the new serialno to use for the
object, not the serialno of the previous revision.</p>
</li>
<li><p class="first">lastTransaction()</p>
<p>Returns the transaction id of the last committed transaction.</p>
</li>
<li><p class="first">lastSerial(oid)</p>
<p>Return the current serialno for <tt class="docutils literal"><span class="pre">oid</span></tt> or None.</p>
</li>
<li><p class="first">iterator(start=None, stop=None)</p>
<p>The iterator method isn't new, but the optional <tt class="docutils literal"><span class="pre">start</span></tt> and
<tt class="docutils literal"><span class="pre">stop</span></tt> arguments are. These arguments can be used to specify
the range of the iterator -- an inclusive range [start, stop].</p>
</li>
</ul>
</blockquote>
<p>FileStorage is now more cautious about creating a new file when it
believes a file does not exist. This change is a workaround for bug
in Python versions upto and including 2.1.3. If the interpreter was
builtin without large file support but the platform had it,
os.path.exists() would return false for large files. The fix is to
try to open the file first, and decide whether to create a new file
based on errno.</p>
<p>The undoLog() and undoInfo() methods of FileStorage can run
concurrently with other methods. The internal storage lock is
released periodically to give other threads a chance to run. This
should increase responsiveness of ZEO clients when used with ZEO 2.</p>
<p>New serial numbers are assigned consistently for abortVersion() and
commitVersion(). When a version is committed, the non-version data
gets a new serial number. When a version is aborted, the serial
number for non-version data does not change. This means that the
abortVersion() transaction record has the unique property that its
transaction id is not the serial number of the data records.</p>
</div>
<div class="section" id="berkeley-storages">
<h2><a name="berkeley-storages">Berkeley Storages</a></h2>
<p>Berkeley storage constructors now take an optional <cite>config</cite> argument,
which is an instance whose attributes can be used to configure such
BerkeleyDB policies as an automatic checkpointing interval, lock table
sizing, and the log directory. See bsddb3Storage/BerkeleyBase.py for
details.</p>
<p>A getSize() method has been added to all Berkeley storages.</p>
<p>Berkeley storages open their environments with the DB_THREAD flag.</p>
<p>Some performance optimizations have been implemented in Full storage,
including the addition of a helper C extension when used with Python
2.2. More performance improvements will be added for the ZODB 3.1
final release.</p>
<p>A new experimental Autopack storage was added which keeps only a
certain amount of old revision information. The concepts in this
storage will be folded into Full and Autopack will likely go away in
ZODB 3.1 final. ZODB 3.1 final will also have much improved Minimal
and Full storages, which eliminate Berkeley lock exhaustion problems,
reduce memory use, and improve performance.</p>
<p>It is recommended that you use BerkeleyDB 4.0.14 and PyBSDDB 3.4.0
with the Berkeley storages. See bsddb3Storage/README.txt for details.</p>
</div>
<div class="section" id="id37">
<h2><a name="id37">BTrees</a></h2>
<p>BTrees no longer ignore exceptions raised when two keys are compared.</p>
<p>Tim Peters fixed several endcase bugs in the BTrees code. Most
importantly, after a mix of inserts and deletes in a BTree or TreeSet, it
was possible (but unlikely) for the internal state of the object to become
inconsistent. Symptoms then varied; most often this manifested as a
mysterious failure to find a key that you knew was present, or that
tree.keys() would yield an object that disgreed with the tree about
how many keys there were.</p>
<p>If you suspect such a problem, BTrees and TreeSets now support a ._check()
method, which does a thorough job of examining the internal tree pointers
for consistency. It raises AssertionError if it finds any problems, else
returns None. If ._check() raises an exception, the object is damaged,
and rebuilding the object is the best solution. All known ways for a
BTree or TreeSet object to become internally inconsistent have been
repaired.</p>
<p>Other fixes include:</p>
<ul class="simple">
<li>Many fixes for range search endcases, including the "range search bug:"
If the smallest key S in a bucket in a BTree was deleted, doing a range
search on the BTree with S on the high end could claim that the range
was empty even when it wasn't.</li>
<li>Zope Collector #419: repaired off-by-1 errors and IndexErrors when
slicing BTree-based data structures. For example,
an_IIBTree.items()[0:0] had length 1 (should be empty) if the tree
wasn't empty.</li>
<li>The BTree module functions weightedIntersection() and weightedUnion()
now treat negative weights as documented. It's hard to explain what
their effects were before this fix, as the sign bits were getting
confused with an internal distinction between whether the result
should be a set or a mapping.</li>
</ul>
</div>
<div class="section" id="id38">
<h2><a name="id38">ZEO</a></h2>
<p>For news about ZEO2, see the file ZEO-NEWS.txt.</p>
<p>This version of ZODB ships with two different versions of ZEO. It
includes ZEO 2.0 beta 1, the recommended new version. (ZEO 2 will
reach final release before ZODB3.) The ZEO 2.0 protocol is not
compatible with ZEO 1.0, so we have also included ZEO 1.0 to support
people already using ZEO 1.0.</p>
</div>
<div class="section" id="other-features">
<h2><a name="other-features">Other features</a></h2>
<p>When a ConflictError is raised, the exception object now has a
sensible structure, thanks to a patch from Greg Ward. The exception
now uses the following standard attributes: oid, class_name, message,
serials. See the ZODB.POSException.ConflictError doc string for
details.</p>
<p>It is now easier to customize the registration of persistent objects
with a transaction. The low-level persistence mechanism in
cPersistence.c registers with the object's jar instead of with the
current transaction. The jar (Connection) then registers with the
transaction. This redirection would allow specialized Connections to
change the default policy on how the transaction manager is selected
without hacking the Transaction module.</p>
<p>Empty transactions can be committed without interacting with the
storage. It is possible for registration to occur unintentionally and
for a persistent object to compensate by making itself as unchanged.
When this happens, it's possible to commit a transaction with no
modified objects. The change allows such transactions to finish even
on a read-only storage.</p>
<p>Two new tools were added to the Tools directory. The <tt class="docutils literal"><span class="pre">analyze.py</span></tt>
script, based on a tool by Matt Kromer, prints a summary of space
usage in a FileStorage Data.fs. The <tt class="docutils literal"><span class="pre">checkbtrees.py</span></tt> script scans a
FileStorage Data.fs. When it finds a BTrees object, it loads the
object and calls the <tt class="docutils literal"><span class="pre">_check</span></tt> method. It prints warning messages
for any corrupt BTrees objects found.</p>
</div>
<div class="section" id="documentation">
<h2><a name="documentation">Documentation</a></h2>
<p>The user's guide included with this release is still woefully out of date.</p>
</div>
<div class="section" id="other-bugs-fixed">
<h2><a name="other-bugs-fixed">Other bugs fixed</a></h2>
<p>If an exception occurs inside an _p_deactivate() method, a traceback
is printed on stderr. Previous versions of ZODB silently cleared the
exception.</p>
<p>ExtensionClass and ZODB now work correctly with a Python debug build.</p>
<p>All C code has been fixed to use a consistent set of functions from
the Python memory API. This allows ZODB to be used in conjunction
with pymalloc, the default allocator in Python 2.3.</p>
<p>zdaemon, which can be used to run a ZEO server, more clearly reports
the exit status of its child processes.</p>
<p>The ZEO server will reinitialize zLOG when it receives a SIGHUP. This
allows log file rotation without restarting the server.</p>
</div>
</div>
<div class="section" id="what-s-new-in-standalonezodb-1-0-final">
<h1><a name="what-s-new-in-standalonezodb-1-0-final">What's new in StandaloneZODB 1.0 final?</a></h1>
<p>Release date: 08-Feb-2002</p>
<p>All copyright notices have been updated to reflect the fact that the
ZPL 2.0 covers this release.</p>
<p>Added a cleanroom PersistentList.py implementation, which multiply
inherits from UserDict and Persistent.</p>
<p>Some improvements in setup.py and test.py for sites that don't have
the Berkeley libraries installed.</p>
<p>A new program, zeoup.py was added which simply verifies that a ZEO
server is reachable. Also, a new program zeopack.py was added which
connects to a ZEO server and packs it.</p>
</div>
<div class="section" id="what-s-new-in-standalonezodb-1-0-c1">
<h1><a name="what-s-new-in-standalonezodb-1-0-c1">What's new in StandaloneZODB 1.0 c1?</a></h1>
<p>Release Date: 25-Jan-2002</p>
<p>This was the first public release of the StandaloneZODB from Zope
Corporation. Everything's new! :)</p>
</div>
</div>
</body>
</html>
Log in
Forgot your password?
