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
ZODB databases).

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to