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 '' 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[1]:  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  -

Reply via email to