Crosspost. Reply-To set to "zodb-dev". Yesterday, I spent a day chasing a mysterious ZEO ClientCache corruption bug: 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 ZODB databases). -- Dieter