Crosspost. Reply-To set to "zodb-dev".
Yesterday, I spent a day chasing a mysterious ZEO ClientCache corruption
A ZEO client implementing a kind of server by forking to process
new requests suddenly started to observe ClientCache corruptions
(after it had run for several years without problem).
The observed corruption was slightly non-deterministic but
quite easily reproducible.
The analysis revealed that the user object that was
logged in by the server (it takes its requests from the ZODB)
has been accessed in the forked process (probably during
the login in the forked process). This access caused
the apparent corruptions.
The ClientCache was not really corrupted but the server
read the wrong data, probably because the
shared file descriptor was moved asynchronously in
the forked child.
This new observation together with hacks I had to introduce
earlier (to prevent the forked child to process
invalidation messages destined for the server)
indicates that it is highly risky to fork when
a ZEO connection has been opened and the forked process
uses the ZODB as well (even when it uses its own storages and
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org