Tim Peters wrote:
The non-zope client has logic that looks roughly like:
for work in queue: try: get_transaction().begin() # do work, change zodb objects, etc get_transaction().commit()
except ConflictError: get_transaction().abort() queue.append(work) except: get_transaction().abort()
Okay, where in the above should I be calling sync()? Where do I get sync from? get_transaction() doesn't have a synch attribute..
You mean apart from that `queue` grows without bound <0.9 wink>?
Well, I'm hoping that things won't conflicterror EVERY time <pi/10 wink>
Type this at Google:
site:mail.zope.org zodb-dev asyncore mainloop
Short course: A ZEO client needs to run an asyncore mainloop if it wants to get invalidations processed "by magic". Alternatives include calling sync(), or closing and (re)opening the connection, at appropriate times.
Hurm, this really should be in bright flashing neon somewhere. I the 5 years this process has been used, I've never known that ZEO don't work right when there's no asyncore loop :-(
Chris - who wants nothing to do with an asyncore loop, ever...
PS: Do the guys working on non-asyncore servers for Z3 know about this limitation?
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
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
