[Zope] Trying to trap ConflictError - Resolved!

[Jonathan]

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