[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:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to