[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

Reply via email to