[ZODB-Dev] Invalidation message question

[Tim Peters]

[Luis Machado]
>> I don't fully understand your answer. My client is read only, and if
>> this is the case you are saying that I can skip this issue entirely.

[Christian Robottom Reis]
> I expressed myself poorly, perhaps. I mean that calling Connection.sync()
> is safe if your client is read-only (since there will never be any
> transaction in progress).

The advice to call Connection.sync() in the client is spot on, but the
motivation still needs clarification:  you're *always* in a transaction.  It
doesn't matter whether your client only reads, it's still in a transaction.
Indeed, it's impossible to explain read conflict errors otherwise.

As Christian said earlier,

    The ZEO client doesn't invalidate the local objects continuously,
    but only at transaction boundaries

A complication is that, prior to ZODB 3.3, while you are in fact always in a
transaction, a Transaction doesn't learn about a Connection unless an object
loaded from that Connection is modified during the transaction.  So prior to
ZODB 3.3, it doesn't do any good for a read-only client to commit() or
abort() the current transaction -- the transaction never learns about the
Connection(s) in use by a read-only client, so aborting the transaction
never tells those Connections that a transaction boundary has occurred.  For
invalidation to occur, it was necessary, but not always *sufficient*, to
cross a transaction boundary.

That's why Connection.sync() is necessary prior to ZODB 3.3 in this case.
Connection.sync() processes invalidations for a Connection regardless of
whether any object loaded from that Connection was modified.

In ZODB 3.3, commit() or abort() should work too:  Connections register with
Transactions in 3.3 regardless of whether an object loaded from a Connection
is modified.  Then, to process invalidations, and unlike as prior to ZODB
3.3, it will be sufficient to cross a transaction boundary.
Connection.sync() will still work, but will look increasingly strange.

There's another reason to call Connection.sync() prior to ZODB 3.3:  a
Connection's in-memory object cache only shrinks at transaction boundaries,
so a read-only client can experience unbounded memory growth unless it
sync's from time to time.