[Chris Withers]
> I have a non-zope zeo client that pumps data into a storage server for
> later consumption by a zope zeo client. Everything is Zope 2.7.5.
>
> 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()
>
> Does anything look amiss there?
You mean apart from that `queue` grows without bound <0.9 wink>?
> The reason I ask is that it works fine, unless someone changes something
> via the zope zeo client resulting in a conflict error on the non-zope
> zeo client. When that happens, the work where the conflict occurs gets
> put back in the queue, but seems to conflict again next time round, even
> though the change on the zope zeo client is long since committed and
> passed. The "work" effectively gets stuck in an endless loop of being
> retried and then conflicterror'ing :-(
>
> Any ideas why that could be?
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.
_______________________________________________
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
