[ZODB-Dev] strange synchronization bug

[Jeremy Hylton]

>>>>> "NH" == Nicholas Henke <henken@seas.upenn.edu> writes:

  NH> The bug I am encountering is:

  NH> A connects via unix socket /tmp/clubmask.zeo to a ZEO server and
  NH> updates root['clubmask']['test'].attr += 1. A is able to
  NH> increment the value of attr with no problems, and will do so
  NH> forever...

  [...]

  NH> I am committing the database in A, but other than that I have no
  NH> idea on how to force A to tell B that the data has changed --
  NH> shouldn't ZEO do this automagically? I would much appreciate any
  NH> and all help :)

You and Neil asked the same question within a day of each other.  You
just phrased it differently :-).

ZEO does do this automatically if you are running an application that
uses an asyncore mainloop.  When one client modifies an object, the
server sends an invalidation message to all the other clients.  If any
of the other clients have a copy of the object loaded, they reload the
object.

The client and storage are implemented using asyncore, which means
they don't do any I/O unless asyncore.loop() or asyncore.poll() are
called.  The invalidation messages will sit in the socket buffer until
the application calls one of these functions.  In Zope, we have a
separate thread that runs asyncore.loop().

If your application doesn't run an asyncore mainloop, then
invalidation messages will only be read when the application calls
into ZEO.  When it calls load() (or anything else), load() will
implicitly call asyncore.poll(), which will process the invalidation
messages.

Neil asked: "Where'd the sync() method go?"  Earlier versions of ZEO
had a sync() method that non-asyncore applications could call the
check for pending I/O.  Guido suggests that we give it a better name.
Tk calls this update(), apparently.

Jeremy