Christian, Thanks. How painfully obvious. I have written the words 'transaction.begin()' about a thousand times or so! But I get discombobulated when I start looking at something new ( ZEO ) and forget the obvious. Final code for this little test that works perfectly:
while True: transaction.begin() root[ "one" ] = "program 2 - " + time.asctime() while True: try: transaction.commit() except POSException.ConflictError: time.sleep(.2) else: break time.sleep(5) tom Christian Theune-2 wrote: > > Hi, > > On 11/26/2009 10:08 PM, James Bergstra wrote: >> On Thu, Nov 26, 2009 at 1:51 PM, tsmiller<tsmil...@gnixterhouse.com> >> wrote: >>> >>> Laurence, >>> Thank you for your very quick reply. I did as you suggested and now the >>> ConflictError is now handled. And that is a most excellent thing >>> because >>> now ConflictError is raised every time. So it still seems to be >>> confused. >>> I am trying to figure out if I will be able to use ZEO in my >>> application. >>> >>> Now my program reads: >>> >>> while True: >>> root[ "one" ] = time.asctime() >>> while True: >>> try: >>> print "Try to commit transaction" >>> transaction.commit() >>> print "root is", root >>> except POSException.ConflictError: >>> print "we have a conflict" >>> transaction.abort() >>> time.sleep(.2) >>> else: >>> break >>> >>> time.sleep(10) >>> >> >> I have a related question about this code... in the inner loop tom is >> calling abort() ; sleep(); commit(). Does that make sense? >> >> I thought that abort() would revert the root to the database's version >> of things, and discard any change that the client had tried to make. >> So what does it mean to call commit() again immediately and why that >> commit cause a conflict when the client hasn't actually changed >> anything since abort() ? > > The abort() actually also marks the point when the next transaction > begins implicitly. > > Your code would work perfectly if whenever you start a transaction, you > simply call transaction.begin(): > > while True: > transaction.begin() > root[.... > > This will cause the time.sleep(2) to not be included in the transaction > and your conflict rate will quickly go down for your example. If you > also use a random factor for the sleep (e.g. between 0.2 and 0.3) then > you'll have a lesser chance of subsequent conflicts in your example > because all your transactions are very similar. In real life > transactions would be distinct enough to cause different offsets in > runtime. > > Hope this helps, > Christian > > -- > Christian Theune · c...@gocept.com > gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany > http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 > Zope and Plone consulting and development > > _______________________________________________ > For more information about ZODB, see the ZODB Wiki: > http://www.zope.org/Wikis/ZODB/ > > ZODB-Dev mailing list - ZODB-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zodb-dev > > -- View this message in context: http://old.nabble.com/newbie-ZEO-first-try.--ConflictError.-tp26532984p26535390.html Sent from the Zope - ZODB-Dev mailing list archive at Nabble.com. _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev