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:

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

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

Reply via email to