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

Reply via email to