[ZODB-Dev] ZEO and replication of BTree based objects

[Christian Reis]

On Wed, Jun 11, 2003 at 10:25:02AM -0400, Tim Peters wrote:
> [Jeremy Hylton]
> >> ZEO uses invalidation-based cache consistency.  When one
> >> client modifies an object, the other clients receive
> >> invalidation messages.  The other clients don't load the
> >> object unless they attempt to read it.
> 
> [Christian Reis]
> > Am I correct in assuming the invalidation messages are only used to
> > raise ReadConflictError when one of the other clients already has a
> > version of the object in its cache?
> 
> Invalidation msgs are the (only) means by which a cache can learn its data
> is stale.  ReadConflictError is a possible consequence of that, but not the
> primary purpose:  the purpose is to ensure that caches don't deliver
> inconsistent data.

By raiding ReadConflictError, I assume (my understanding is that RCE
means you have stale data in your hand. Or how else would notifications
be treated?).

> If, for example, you call the .sync() method on a

You say "for example", but is sync() the only other way invalidated
cache entries are actually important?

> connection object, that handles pending invalidations (purges invalidated
> objects) without raising ReadConflictError.  I think <wink>.

Well, it *does* call _flush_invalidations, but it also aborts the current
transaction (which is not a lot of fun). Would just flushing the
invalidations be a way to make sure our objects are non-stale? I suppose
the nasty bit here is that the current transaction may have modified
these objects, or done something based on changes in these objects, and
now we can't be sure if our data is sane or not.

But in certain cases, this would allow for `selective cache updates',
which is something really nice when all you want to do is grab a
reference to an object you just created in another transaction (without
aborting the current one).

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL