Thanks for the feedback. In this specific case we need a cache that can
be shared by ZEO clients and since ram cache uses a module level cache
it won't work. It looks like memcached will work fine though.
Upfront Systems http://www.upfrontsystems.co.za
On Mon, 2008-10-20 at 17:57 -0500, Alan Runyan wrote:
> I would not imagine this functionality is not in scope of the ZODB. We
> were thinking about piggy backing on top of the invalidation messages
> sent from ZEO server at one point.. cant remember why we gave up on
> For various reasons:
> - The object may not be loaded on the "other" zeo client; therefore
> why should it be notified?
> - If you have a lot of changes it could generates oodles of
> messages; significantly degrading ZODB performance.
> The best thing is to look into a messaging library. AMQP is pretty
> rockin. I spoke w/ Stefan Richter and they are using Amazon's
> messaging platform. I believe what you are looking for is some sort of
> application level messaging across ZEO clients.
> Kapil has started an implementation at repoze.queue (I would prefer
> the name repoze.messaging) which may not yet have an implementation
> other than the interfaces and some tests. But this is a known problem
> (which is very hard to get right).
> On Mon, Oct 20, 2008 at 2:36 PM, Roché Compaan
> <[EMAIL PROTECTED]> wrote:
> > If an object is modified on one ZEO client, will this always lead to a
> > __setstate__ call on this object on another ZEO client?
> > If not, is there any event or method that I can hook into to determine
> > if an object was modifed by another ZEO client?
> > --
> > Roché Compaan
> > Upfront Systems http://www.upfrontsystems.co.za
> > _______________________________________________
> > For more information about ZODB, see the ZODB Wiki:
> > http://www.zope.org/Wikis/ZODB/
> > ZODB-Dev mailing list - ZODB-Dev@zope.org
> > http://mail.zope.org/mailman/listinfo/zodb-dev
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org