Tres Seaver wrote:
> I've got a question for you on the removal of the LISTEN / NOTIFY stuff
> in the Postgresql adapter: it looks to me as though your code was not
> doing the async check-for-notifies as shown in the 'notify.py' in the
> psycopg2 examples:
> So, any notifies you got were only capture on the basis of "syncrhonous"
> activity (a cursor doing some other work). Could that explain the
> unreliability which caused you to remove it? The symptom would be like
> the time that the ZEO async stuff got dropped in Zope3 during the
> Twisted integration: a "busy" client would stay up to date, but an
> idle one would serve stale objects from cache.
It does appear that a short select() loop is required. However, I tried
that and learned that notifications have no timeliness guarantees. The
current model requires strict timeliness of change notification in order
to maintain ZODB consistency.
However, I think we can still take advantage of listen and notify in a
slightly different way. Currently, the Postgres adapter rolls back the
load transaction on every connection close, but if it instead leaves the
session idle with a transaction open, it would be safe for RelStorage to
sometimes ignore new changes and only roll back and poll after an async
notification arrives. I could see scalability going way up that way, as
long as Postgres doesn't mind all the idle sessions with an open
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org