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: > > http://www.initd.org/tracker/psycopg/browser/psycopg2/trunk/examples/notify.py > > 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 transaction. Shane _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
