avoid spurious errors on exit, especially for scripts, such as zeopack.

references across databases when the referenced database has an empty
name.

was astronomical.  Also greatly simplified the code.

- Cache records are written in several stems.  If a process exits
    after writing begins and before it is finishes, the cache will be
    corrupt on restart.  The way records are writted was changed to
    make cache record updates atomic.

- There was no lock file to prevent opening a cache multiple times
    at once, which would lead to corruption.  Persistent caches now
    use lock files, in the same way that file storages do.

- A bug in the cache-opening logic led to cache failure in the
    unlikely event that a cache has no free blocks.

When using ZEO Client Storages, Errors occured when trying to store
objects too big to fit in the ZEO cache file.

(backport from trunk)

(backport from trunk)

versions of objects.

uncommitted data is placed.

(hang). This was accomonied by a critical log message along the
lines of: "RuntimeError: dictionary changed size during iteration".

actively preventing it.

r77078 | gary | 2007-06-25 16:39:45 -0400 (Mon, 25 Jun 2007) | 1 line
r77010 | gary | 2007-06-24 13:19:18 -0400 (Sun, 24 Jun 2007) | 2 lines
r76977 | gary | 2007-06-23 06:57:51 -0400 (Sat, 23 Jun 2007) | 1 line
r76953 | gary | 2007-06-23 00:20:55 -0400 (Sat, 23 Jun 2007) | 1 line

Document conflict resolution. bugfix the situation in which comparing
persistent objects (for instance, as members in BTree set or keys of
BTree) might cause data inconsistency during conflict resolution.
support multidatabase references in conflict resolution.  make it
possible to examine oid and (in some situations) database name of
persistent object references so that I can add some code to
zope.app.keyreference to support these objects (so BTree conflict
resolution can happen at all when keyreferences are used).

   closed connections.

  improved in the case that servers are restarted.  Before, if
  transactions were committed after the restart, clients that were up
  to date or nearly up to date at the time of the restart and then
  connected had to verify their caches.  Now, it is far more likely
  that a client that reconnects soon after a server restart won't have
  to verify its cache.

- Fixed a serious bug that could cause clients that disconnect from and
  reconnect to a server to get bad invalidation data if the server
  serves multiple storages with active writes.

(Merged from 3.7 branch.)

These are the ZODB part of the patches I posted to
http://www.zope.org/Collectors/Zope3-dev/655 with an additional import cleanup.
The issue was silent for over 2 weeks.

Also my attempts at subscribing to zodb-dev or sending a message there
dissapeared were doomed;)

I'm fully willing to revert this if someone has an issue with it.

    ------------------------------------------------------------------------
    r70059 | jinty | 2006-09-08 16:26:44 +0200 (Fri, 08 Sep 2006) | 1 line

    Forgot the NEWS entry. Hope I did it right.
    ------------------------------------------------------------------------
    r70053 | jinty | 2006-09-08 14:43:26 +0200 (Fri, 08 Sep 2006) | 1 line

    Clean up wierd import dance with ZODB. This is unnecessary since the transaction module stopped being imported in ZODB/__init__.py in rev 39622.
    ------------------------------------------------------------------------
    r70051 | jinty | 2006-09-08 13:24:45 +0200 (Fri, 08 Sep 2006) | 1 line

    Add the ability to ask a transaction if it has been doomed i.e. isDoomed().
    ------------------------------------------------------------------------
    r70050 | jinty | 2006-09-08 13:13:06 +0200 (Fri, 08 Sep 2006) | 1 line

    Add the doom() function to transactions. Look at tests/doom.txt for more info.
    ------------------------------------------------------------------------