I had a problem like that, and I had to explicitely sync() the connection before begin(), I think.
Florent Chris Withers <[EMAIL PROTECTED]> wrote: > Hi there, > > 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? > > 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? > > cheers, > > Chris > > -- > 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 > -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] _______________________________________________ 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
