[Zope] Trying to trap ConflictError - Resolved!
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