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

[Tim Peters]

[Christian Reis]
> 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?).

Actually, ReadConflictError is not raised if you have stale data in your
cache.  It's raised if you don't have a live object in your cache, try to
load that object, and that object has been invalidated.  In short, that
means some other transaction modified the object before you tried to load
it, and after your transaction (the one trying to load the object) began.
ReadConflictError is then trying to save you from loading *inconsistent*
data.  It's complicated.

>> 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?

Jeremy said before that cache consistency is invalidation-based.  IOW,
invalidation is the heart and soul of it:  nothing works right without it.
So "the only other way ... are actually important" doesn't make sense in
this context, because invalidation *is* the cache coherence mechanism.  So,
sure, apart from that we need air to breathe, air plays no other role in
breathing's contribution to survival <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).

I have to leave comments on this to someone else.