Dieter Maurer wrote:
> I am surprised that you think to be able to play with the polling
> frequency.
>   Postgres will deliver objects as they have been when the
>   transaction started.
>   Therefore, when you start a postgres transaction
>   you must invalidate any object in your cache that
>   has been modified between load time and the begin of this
>   transaction. Otherwise, your cache can deliver stale state
>   not fitting with the objects loaded directly from Postgres.
>   I read this as you do not have much room for manouver.
>   You must ask Postgres about invalidations when the transaction
>   starts.

Yes, quite right!

However, we don't necessarily have to roll back the Postgres transaction
on every ZODB.Connection close, as we're doing now.  If we leave the
Postgres transaction open even after the ZODB.Connection closes, then
when the ZODB.Connection reopens, we have the option of not polling,
since at that point ZODB's view of the database remains unchanged from
the last time the Connection was open.

It's not usually good practice to leave sessions idle in a transaction,
but this case seems like a good exception since it should significantly
reduce the database traffic.


For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to