[ZODB-Dev] ZEO Client cache invalidation?

[Greg Ward]

On 05 July 2001, Christian Robottom Reis said:
> I've built up an app using a FileStorage, and now I've migrated to the
> ZEO. I'm having a bit of trouble, however, having changes being noticed in
> the clients. Scenario: client A inserts object F into catalog which is an
> element of root. Client B doesn't pick up the change until we restart it.

The Connection class has a 'sync()' method which does exactly what you
want.  Eg. in our web application, we do

  get_connection().sync()

before processing every HTTP request (get_connection() is ours, it just
returns a Connection object squirreled away in some module global
somewhere).  Works like a charm.  (This didn't work in old versions of
ZEO, but as long as you're running one of the 1.0 betas it should be
OK.)

Note that this is not the most efficient way of working, as it involves
a bit of database mechanics -- invalidate parts of the cache, maybe
reload some objects (not sure how it works) -- when our server should be
off processing the user's request.  The way Zope does it is, as usual,
clever, subtle, a bit more efficient, and not at all obvious.  It
requires the application using ZEO (Zope in this case) to be structured
around an asyncore main loop; the client side of ZEO (ClientStorage I
guess) registers a bit of code with asyncode to handle "certain
communications" from the ZEO server (I'm not sure what distinguishes
those communications) that announce "someone else just committed objects
3, 7, and 19 -- you'd better invalidate and/or reload them".  I'm not
sure if ClientStorage just invalidates those objects in its cache or
actually reloads them -- either way, it means Zope doesn't have to do an
explicit Connection.sync() on every hit, because it's done
behind-the-scenes between hits.

My brain hurts,

        Greg