----- Original Message ----- From: <dieter@handshake.de> To: "Jonathan" <dev101@magma.ca> Cc: "Michael Dunstan" <michael.dunstan@gmail.com>; <zope@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 error.
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!!! Jonathan