[Zope] Trying to trap ConflictError - Resolved!

Jonathan dev101 at magma.ca
Thu Jul 6 16:29:00 EDT 2006

----- Original Message ----- 
From: <dieter at handshake.de>
To: "Jonathan" <dev101 at magma.ca>
Cc: "Michael Dunstan" <michael.dunstan at gmail.com>; <zope at zope.org>
Sent: Thursday, July 06, 2006 2:56 PM
Subject: Re: [Zope] Trying to trap ConflictError

> Jonathan wrote at 2006-7-6 09:53 -0400:
>> ...
>>>From what I understand from the above code, the error is being raised
>>because the oid already exists and the object pointed to by the old oid is
>>different from the object pointed to by the new oid, hence the conflict
> You interpretation is slightly wrong. What really differs is not
> the object (or "oid") but the timestamp.
> Each persistent object has a timestamp "_p_serial" which
> identifies the transaction that made the last change to the object.
> When an object is loaded from the ZODB, its timestamp is
> recorded (in "_p_serial"). When later a change to the object
> should be commited, the recorded timestamp is compared to the object's
> current timestamp in the ZODB. If the timestamps differ, then
> the object was modified by a concurrent transaction and our
> modification is likely to be based on stale information.
> As a result a "ConflictError" is raised.

Thanks Dieter, this got me pointed in the right direction...

The problem was due to multiple processes simultaneously accessing a 
'MakeId' routine (as some had suggested earlier in this investigation!). 
Even though the routine returned a 10 digit id consisting of a 7 digit 
timestamp + 3 random digits, there were still id collisions.

Changing the MakeId routine to return a 10 character string (all 10 
characters randomly generated) eliminated the ConflictErrors that were 
occurring during heavy load testing.

Thanks to everyone for the great assistance!!!


More information about the Zope mailing list